FAQ last updated 01-May-96.
SSLeay is a free implementation of Netscape's Secure Socket Layer - the software encryption protocol behind the Netsite Secure Server and the Netscape Browser.
This implementation was coded from scratch using only the publicly available documentation of the various protocols by Eric Young eay@mincom.com.
The initial prompting to tackle an SSL implementation, the alpha testing, SSL developer (i.e. Eric) hassling, and documentation was done by Tim Hudson tjh@mincom.com.
This implementation has been used by Tim Hudson tjh@mincom.com to add SSL support to the following:
The following applications are also now available based on the earlier work with input from others:
The following are available:
SSLeay supports the following encryption algorithms:
This documentation is Copyright Tim Hudson tjh@mincom.com See the COPYRIGHT file for the usage and redistribution restrictions.
Note: a nicely formatted postscript version of this document is included in the file SSLeay.doc-version.tar.gz (in the same directory as the SSLeay source).
That is one of the hard questions on which there is as yet no clear answer. You need to read quite a bit of information (see the RAMBLINGS file in the SSLeay source distribution) to draw your own conclusions - and then go and talk to a lawyer. Again this document is my opinion and as such should be treated in that light - reality could be quite different to how I happen to see things :-).
In short:
Nothing. The package itself is free. There are a couple of minor conditions which are outlined clearly in the COPYRIGHT file in the source distribution. In short - attribution is mandatory, and no publicly available version of this code can have a different license.
Yes. Free of charge. Read the license carefully (see the COPYRIGHT file in the SSLeay source distribution).
At present the documentation from a programmer's point of view is fairly light and you really need to work through the same code that is included in the library itself and have a look at how the patches are put together. It is fairly straight forward to add SSL support to an existing application.
Most of the issues that need to be considered if you are going to start using SSL either as an end user or as a developer are covered in the documentation - certainly there needs to be more work done on this documentation; however reading the documentation should answer most questions (and raise quite a few more too).
Eric has finally been hassled into starting documentation on the library itself ... see the doc directory in the SSLeay distribution. This documentation will be turned into a more verbose manual over then next few months.
The best starting point is to look at example code ... either in the sample client and server program included with SSLeay or in any of the patched applications - the structure of each of the applications internally is quite similar.
Sources for the library and the applications can be found in the following locations:
The SSLeay Programmer Reference is located at
Note: the SSLeay Programmer Reference is in the process of being updated to SSLeay-0.5 so what is there doesn't exactly match the current version.
This (believe it or not) has been the most commonly asked question so far.
The whole dependence on RSA (actually now Verisign) for certificates is because Netscape browsers at release 1.x do not allow the user to configure which Certifying Authorities are trusted and only trust four hardcoded CAs.
The Netscape Navigator starting with release 2.x (beta) supports user configurable CAs. If the user connects to service that is using a certificate that is not signed by one of the hardcoded CAs then the user is asked if they want to add it to the list of trusted CAs. This basically means that the security trust policy is now in the hands of the user.
So in summary: for the old version of the Netscape Navigator (v1.x) the answer is rather simple: yes if and only if you have a certificate signed by Verisign or Netscape (which cost $US200-$US300). This has been tested by quite a few people (including myself now) and does indeed work. For the new versions (v2.x) this is no longer a "problem".
Verisign have changed their policy on issuing certificates such that certificates will only be issued for use with registered applications (and SSLeay itself doesn't fit in any of their current categories).
Those that currently have certificates signed by Verisign will not have them renewed unless the software being used is on the registered application list. This is a rather interesting and unusual situation.
Note: Please communicate your displeasure directly to Verisign if you think that their policy in this area should be changed. Feedback from potential customers that will not deal with them is the only way I can see of encouraging them to change this policy. Personally I think that this is a rather short sighted business decision and opens the way for other Certifying Authorities to more easily establish a market.
If you already have a certificate from RSA can you (legally) use it with an SSLeay-ized httpd? This may be okay if you have linked with RSAREF. Outside of the USA this isn't an issue as far as I am aware. However if you want the Netscape browser to work in secure mode then you will still need an RSA or Netscape signed certificate for your server.
You really should read the details of the process that Alex Tang altitude@cic.net has been through if you are "blessed" with being inside the USA. This is detailed at http://petrified.cic.net/~altitude/ssl/ssl.saga.html and makes quite "interesting reading".
The patches to Mosaic were done so that there is no checking of the certificate of the server such that Mosaic will connect and work with any of the existing Netsite secure servers without a problem. This however is probably not the policy you should run if you are planning on issuing credit card transactions - the client should have some form of security verification procedure in place where it checks the server against a trusted list before handing over any important information.
Exactly how the whole certificate management and authorisation process is going to work on a global basis is really unknown at this stage.
Rather simply put, we need people who are prepared to contribute to the effort under the same conditions that we work (which is simply attribution is mandatory but everything generated is totally free otherwise) so that we have a wider supported set of applications. If you do add SSL support to an application please drop us a line (and the patches if at all possible).
However if you wish to send donations of almost any form, neither of us will say no and it may influence what we work on next and how quickly things are done.
If you have access to a Unix varient that we do not and you are well connected (bandwidth-wise) and don't mind a little extra load then we can speed up the spread of the SSL applications (the library itself is very portable - it's the applications (at the moment) that are significantly less so.
Also join the ssl-users@mincom.com mailing list (send email to ssl-users-request@mincom.com for instructions for using the majordomo varient that manages this list - which in short are send mail to factotum@mincom.com with a message body of subscribe ssl-users).
Tom Kee tom.kee@magnets.com maintains an archive of the mailing list at http://www.magnets.com/lists/
Holger Reif Holger.Reif@PrakInf.TU-Ilmenau.DE also maintains an archive at //remus.prakinf.tu-ilmenau.de/ssl-users/
For those who like to drive everything via WWW browsers here is a list of those things you might want to grab - always be aware that this document lags behind what is actually sitting on the ftp servers.
Details (and some replication of bits of this document) can be found >here< .
Well, as this in an unpaid effort there is no guarantee of support (you get what you pay for :-); however there is a mailing list which has those people subscribed to it who are interested in SSLeay and it's furthur development.
Join the ssl-users@mincom.com mailing list (send email to ssl-users-request@mincom.com for instructions for using the majordomo varient that manages this list - which in short are send mail to factotum@mincom.com with a message body of subscribe ssl-users).
Eric Young eay@mincom.com
Tim Hudson tjh@mincom.com
Or to get hold of both of us (which is probably the "right" thing to do for most questions) use ssleay@mincom.com
Eric concentrates on the library side of thing and Tim (me) has done all the applications and documentation; however it is better to contact both of us unless it's a really specific question as we do know what each other is working on and work different hours (and have different opinions on some things too :-) and take holidays at different times.
Thanks to Tom Kee tom.kee@magnets.com there is an archive of ssl-users at http://www.magnets.com/lists/
If you are outside of the USA and not covered by legal restrictions on the export and import of encryption technology then drop us a line if you are prepared to mirror the SSLeay distribution and you will be added to this list.
Andreas Bogk bogk@inf.fu-berlin.de mirrors the SSLeay distribution (updated every 24 hours) in the following location:
Christoph Martin christoph.martin@uni-mainz.de mirrors the SSLeay distribution (updated every 24 hours) in the following location:
The German CERT server in Hamburg
For those close to Finland
Panu Rissanen bande@nic.funet.fi mirrors SSLeay updated biweekly at:
Sites in Sweeden
Tein Yuan tyuan@beta.wsl.sinica.edu.tw mirrors SSLeay related stuff at:
Sites in Korea
Lee, Ho-sun ahmlhs@cair.kaist.ac.kr mirrors SSLeay related stuff at:
Sites in Japan
Takahiro Kiuchi kiuchi@rick.epistat.m.u-tokyo.ac.jp mirrors SSLeay related stuff at:
Sites in the UK
Steve Kennedy steve@gbnet.net mirrors SSLeay updated daily at:
Is there a Windows version of SSLeay and the applications to go with it? The answer is that the technical port is complete and has been released as a separate distribution of files for building using Borland C++ 4.0.
SSLeay-0.4.5d "supports" Microsoft Windows 3.1 as a series of DLLs (this stuff really is pre-alpha at the moment - but at least the majority of the "interesting" work has been done). Note that this is being updated to the new SSLeay-0.5 release at the moment before being generally released again. This is still a few more weeks away from being available
Again, if you wish to help with this continuing effort (and are also a competant MS Windows programmer) then send email to tjh@mincom.com.
And for porting notes for the following applications:
4.4BSD-Lite telnet (NEtelnet) patches done by Christoph Martin christoph.martin@uni-mainz.de are located at:
Note: Christoph and myself are in the process of merging our code to get back to having a single version of the source.
The SSL Protocol Specification is detailed at http://home.netscape.com/newsref/std/SSL.html
SSLRef (The Netscape Reference Implementation of SSL) is located at http://home.netscape.com/newsref/std/sslref.html
There is also a mailing list for discussion of SSL run by Netscape at ssl-talk@netscape.com. You can join this list by sending mail to ssl-talk-request@netscape.com with subscribe as the subject line or the message body.
The first fully functional version of Apache with SSL support was implemented by Ben Laurie ben@algroup.co.uk. This server is probably the best choice at the moment if you are looking for a commercial-strength SSL capable WWW server.
Apache-SSL-US (which is now also known as Stronghold) is available within the USA for commercial and non-commercial use from Community ConneXion. See http://apachessl.c2.org for more information.
Note: this release is built against RSAREF.
SSL support for CERN httpd was implemented by Gertjan van Oosten gertjan@West.NL. See http://www.west.nl/archive/cern_httpd/HTTPS.patch for the patches.
A rather extensive list of cryptographic material is maintained at http://www.cs.hut.fi/crypto/ and a handy list of publicly available software is available directly at http://www.cs.hut.fi/crypto/software.html.
Also there is a good overview of certificate services in general available from RSA at ftp://ftp.rsa.com/pub/csc/docs/wp.eps. It is a 40 page July 1993 document that is good background reading.
To start things rolling with a server you will need to generate a certificate. There is a quick way to generate a "dummy" self-signed certificate for testing purposes or if you are not using the certificate for authentication.
PATH=$PATH:/usr/local/ssl/bin # SSLeay 0.5.0b+ (21-Dec-95) supports a quick mechanism for generating # "dummy" certificates cd /usr/local/ssl/certs req -new -x509 -nodes -out telnetd.pem -keyout telnetd.pem ln -s telnetd.pem `x509 -noout -hash < telnetd.pem`.0
Then *test* that verify likes the setup
verify /usr/local/ssl/certs/telnetd.pem
It is fairly easy with SSLeay-0.5.x to do this. Grab der_chop from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/der_chop and read the instructions inside it.
der_chop < ServerCert.der > cert.pem
Convert and encrypt it again to protect the key
rsa -inform NET -in ServerKey.der -des > key.pem
There is a ca program in SSLeay-0.5.x that includes the initial support for basically operating as your own certifying authority.
I've wrapped a script around it to make it a little easier to work with in the short term while Eric is busy thinking about what to add next and you can get it from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/CA. The CA shell script has the following sorts of options:
CA -newca ... will setup the right stuff for using ca CA -newreq ... will generate a certificate request CA -sign ... will sign the generated request and output a cert
Documentation for ca itself is very light on this but here are the basics:
The ca program uses the ssleay.conf file for most of its configuration. You will want to read through this file and customise it to match your own requirements.
Use ca -help for the standard brief usage instructions. The follow documents more information and is not yet complete but should have enough information to encourage you to experiment.
ca supports the concept of policies to define the order of fields certificate request and what fields are mandatory at what attributes get filled in.
The options for each policy are stored in sections in the configuration file (the default configuration file is called ssleay.conf)
Sections in the configuration file basically match the "normal" Windows INI file concept of named lists of variables with values.
[section name] variable1=value variable2=value
In the config file, the section to use for parameters. This lets multiple setups to be contained in the one file. By default, the default_ca variable is looked up in the [ ca ] section. So in the shipped ssleay.conf, the CA definition used is CA_default. It could be any other name.
This will generate a new certificate revocation list.
When certifiying certificates, this is the number of days for which the certified certificate is valid - i.e. the number of days from now at which the certificate will expire.
These are described later. There are 2 policies definied in the default ssleay.conf configuration file.
We always want to keep the CA's RSA key encrypted!
The -out options concatenate all the resultant certified certificates to one file, -outdir puts them in a directory, named by serial number.
Most parameters have their default values defined in the configuration file ssleay.conf (and naturally the standard defaults are reasonable :-).
The standard defaults for most of the options are in ssleay.conf in the "section" CA_default.
---------------------------------------------------------------------------
name description
---------------------------------------------------------------------------
dir where all the CA database stuff is kept.
certs where all the previously issued certificates are kept.
database file a simple text database containing a record of the status of
issued certificates
policy the default policy name
---------------------------------------------------------------------------
The policy section specifies the requirements for each of the "objects" that go into the certificates in the terms of:
The defaults for policy_match are
countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional
The order in which the "objects" are listed in the policy section is the order in which they will occur in the generated certificate.
status: a value of 'R' - revoked, 'E' -expired or 'V' valid. issued date: When the certificate was certified. revoked date: When it was revoked, blank if not revoked. serial number: The certificate serial number. certificate: Where the certificate is located. CN: The name of the certificate.
Note: The demo file has quite a few made up values it it. The last 2 were added by the ca program and are acurate.
The ca program does not update the 'certificate' filed correctly right now. The serial field should be unique as should the CN/status combination be correct. The ca program checks these at startup. What still needs to be written is a program to 'regenerate' the database file from the issued certificate list (and a CRL list).
If you think about how the Persona requests operate, it is similar to the policy_match policy and the policy_anything is similar to what Verisign are doing.
If you have any problems with SSLeay then please take the following steps:
Note: if using gcc then remove -fomit-frame-pointer before you try to debug things.
If you wish to report a bug then please include the following information in any bug report: (perhaps I should turn this into a bug submission FORM?)
SSLeay Details
- Version
Operating System Details
- OS Name
- OS Version
- Hardware platform
Compiler Details
- Name
- Version
Application Details
- Name
- Version
Problem Description
- include steps that will reproduce the problem (if known)
Stack Traceback (if the application dumps core)
For example:
SSLeay-0.5.1a SunOS 5.3, SPARC, SunC 3.0 SSLtelnet-0.7 Core dumps when using telnet with SSL support in bn_mul() with the following stack trackback ...
Report the bug to either ssleay@mincom.com (Eric and Tim) or ssl-bugs@mincom.com (mailing list of active developers)
See ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/PORT4-5 notes for brief details on the most visible changes.
If you happen to wish to send non-plaintext email then the following is the PGP key for tjh@mincom.com. (And yes I do know that the key size is small).
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQBNAjEqnRQAAAECAK1c6Mg2fS98Mhj8IXlXj0+qCwmjklRMty3Uq7yHhE1iNCED wZH51I3gG+HiN7AE4L1+qfjT16v+yEU66UDAzrUABRO0G1RpbSBIdWRzb24gPHRq aEBtaW5jb20uY29tPg== =2NyS -----END PGP PUBLIC KEY BLOCK-----
The following is a list of the commercial software that I know about that use SSLeay.
If you wish to have your product added to this list then drop me email at tjh@mincom.com with the brief details that you would like added.
StrongHold (which was originally known as Apache-SSL-US) is available within the USA for commercial and non-commercial use from Community ConneXion. See http://apachessl.c2.org for more information.
Note: this release is built against RSAREF.
Sioux is a secure web server based on Apache and SSLeay. Binaries available from ftp://ftp.thawte.com/pub/products/sioux/ Documentation and other information is available at http://www.thawte.com/products/sioux/