|SSL(8)||System Manager's Manual||SSL(8)|
The SSL libraries (libssl and libcrypto) implement the SSL version 2, SSL version 3, and TLS version 1 protocols. SSL version 2 and 3 are most commonly used by the https protocol for encrypted web transactions, as can be done with httpd(8). The libcrypto library is also used by various programs such as ssh(1), sshd(8), and isakmpd(8).
It is important to remember when using a random data source for certificate and key generation that the random data source should not be visible by people who could duplicate the process and come up with the same result. You should ensure that nobody who you don't trust is in a position to read the same random data used by you to generate keys and certificates. The arandom(4) device ensures that no two users on the same machine will see the same data. See openssl(1) for more information on how to use different sources of random data.
Private keys can be encrypted using AES and a passphrase to protect their integrity should the encrypted file be disclosed. However, it is important to note that encrypted server keys mean that the passphrase needs to be typed in every time the server is started. If a passphrase is not used, you will need to be absolutely sure your key file is kept secure.
# openssl genrsa -out /etc/ssl/private/server.key 2048
Or, if you wish the key to be encrypted with a passphrase that you will have to type in when starting servers
# openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
The next step is to generate a Certificate Signing Request which is used to get a Certificate Authority (CA) to sign your certificate. To do this use the command:
# openssl req -new -key /etc/ssl/private/server.key \ -out /etc/ssl/private/server.csr
This server.csr file can then be given to a Certificate Authority who will sign the key.
You can also sign the key yourself, using the command:
# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \ -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
With /etc/ssl/server.crt and /etc/ssl/private/server.key in place, you should be able to start httpd(8) with the -DSSL flag, enabling https transactions with your machine on port 443.
You will most likely want to generate a self-signed certificate in the manner above along with your certificate signing request to test your server's functionality even if you are going to have the certificate signed by another Certificate Authority. Once your Certificate Authority returns the signed certificate to you, you can switch to using the new certificate by replacing the self-signed /etc/ssl/server.crt with the certificate signed by your Certificate Authority, and then restarting httpd(8)
# openssl dsaparam 1024 -out dsa1024.pem
Would generate DSA parameters for 1024 bit DSA keys, and save them to the file dsa1024.pem.
Once you have the DSA parameters generated, you can generate a certificate and unencrypted private key using the command:
# openssl req -x509 -nodes -newkey dsa:dsa1024.pem \ -out /etc/ssl/dsacert.pem -keyout /etc/ssl/private/dsakey.pem
To generate an encrypted private key, you would use:
# openssl req -x509 -newkey dsa:dsa1024.pem \ -out /etc/ssl/dsacert.pem -keyout /etc/ssl/private/dsakey.pem
For instance, another typical alternative is DSA, which is not encumbered by commercial patents (and lawyers).
The https protocol used by web browsers (in modern incarnations) allows for the use of SSL version 3 and TLS version 1, which in theory allows for encrypted web transactions without using RSA. Unfortunately, all the popular web browsers buy their cryptographic code from RSADSI. Predictably, RSADSI would prefer that web browsers used their patented algorithm, and thus their libraries do not implement any non-RSA cipher and keying combination. The result of this was that while the https protocol allowed for many cipher suites that did not require the use of patented algorithms, it was very difficult to use these with the popular commercially available software. Prior to version 2.8, OpenBSD allowed users to download RSA enabled versions of the shared libssl and libcrypto libraries which allowed users to enable full function without recompiling the applications. This method is now no longer needed, as the fully functional libraries ship with the system. However, this entire debacle is worth remembering when choosing software and vendors.
This document first appeared in OpenBSD 2.5.
|September 29, 2011||OpenBSD-5.1|