TABLE OF CONTENTS

This document describes some of the issues relating to the use of the OpenSSL
libssl and libcrypto libraries. This document is intended as an overview of
what the libraries do, and what uses them.

The libssl and libcrypto libraries implement the TLS version 1 protocol. It is
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).

The most common uses of TLS will require you to generate a server certificate,
which is provided by your host as evidence of its identity when clients make
new connections. The certificates reside in the
/etc/ssl directory, with the keys in the
/etc/ssl/private directory.

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.

Note that some new browsers have deprecated using the common name of a
certificate and require that subject alt names are provided. This may require
the use of -extfileserver.ext when self-signing.

# this is an example server.ext file
subjectAltName=DNS:example.com,DNS:www.example.com

With /etc/ssl/server.crt and
/etc/ssl/private/server.key in place, you
should be able to start httpd(8)
with SSL configured, 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).

Prior to Sept 21, 2000, there were problems shipping fully functional
implementations of these protocols, as such shipment would include shipping
into the United States. RSA Data Security Inc
(RSADSI) held the patent on the RSA algorithm in the United States, and
because of this, free implementations of RSA were difficult to distribute and
propagate. (The RSA patent was probably more effective at preventing the
adoption of widespread international integrated crypto than the much maligned
ITAR restrictions were.) Prior to OpenBSD 2.8, these
libraries shipped without the RSA algorithm -- all such functions were stubbed
to fail. Since RSA is a key component of SSL version 2, this meant that SSL
version 2 would not work at all. SSL version 3 and TLS version 1 allow for the
exchange of keys via mechanisms that do not involve RSA, and would work with
the shipped version of the libraries, assuming both ends could agree to a
cipher suite and key exchange that did not involve RSA. Likewise, the SSH1
protocol in ssh(1) uses RSA, so it
was similarly encumbered.

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 functionality 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.

Due to multiple flaws in the protocols, SSL version 2 was removed in
OpenBSD 5.2 and SSL version 3 was disabled in
OpenBSD 5.7. Users and programs should use TLS version
1.2 instead.