*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->OpenBSD man pages -> ssl (8)              



NAME    [Toc]    [Back]

     ssl - details for libssl and libcrypto

DESCRIPTION    [Toc]    [Back]

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

RANDOM DATA SOURCE    [Toc]    [Back]

     OpenBSD uses the arandom(4) device as the default source for
random data
     when needed by the routines in libcrypto and libssl.  If the
     device does not exist or is not readable, many of  the  routines will fail.
     This  is  most  commonly  seen  by users as the RSA routines
failing in applications
 such as ssh(1), and httpd(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.


     The most common uses of SSL/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

     Private keys can be encrypted using 3DES and a passphrase to
     their integrity should  the  encrypted  file  be  disclosed.
However, it is
     important  to  note that encrypted server keys mean that the
     needs to be typed in every time the server is started.  If a
     is  not  used,  you will need to be absolutely sure your key
file is kept


     Generating a DSA certificate involves several steps.  First,
you generate
     a DSA parameter set with a command like the following:

           # 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


     To  support  https transactions in httpd(8) you will need to
generate an
     RSA certificate.

           # openssl genrsa -out /etc/ssl/private/server.key 1024

     Or,  if  you  wish the key to be encrypted with a passphrase
that you will
     have to type in when starting servers

           # openssl  genrsa  -des3  -out  /etc/ssl/private/server.key 1024

     The  next  step is to generate a Certificate Signing Request
which is used
     to get a Certifying 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  Certifying
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
     signed by another Certifying Authority.  Once your  Certifying 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 Certifying Authority, and then

     By default, sendmail(8) expects both the keys  and  certificates to reside
     in  /etc/mail/certs, not in the /etc/ssl directory.  The default paths may
     be overridden in the sendmail.cf file.  See starttls(8)  for
     on configuring sendmail(8) to use SSL/TLS.

SEE ALSO    [Toc]    [Back]

     openssl(1),  ssh(1),  ssl(3),  arandom(4),  httpd(8), isakmpd(8), rc(8),
     sendmail(8), sshd(8), starttls(8)

HISTORY    [Toc]    [Back]

     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.
     the SSH1 protocol in ssh(1) uses RSA, so  it  was  similarly

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

BUGS    [Toc]    [Back]

     The world needs more DSA capable SSL and SSH services.

OpenBSD     3.6                       September     19,      2001
[ Back ]
 Similar pages
Name OS Title
siginfo Tru64 Details of signal generation
glxqueryhyperpipeconfigsgix IRIX Query the details of a hyperpipe configuration
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service