[ Team LiB ] Previous Section Next Section

Recipe 4.8 Creating a Self-Signed SSL Certificate

4.8.1 Problem

You want to create an SSL certificate but don't want to use a well-known certifying authority (CA), perhaps for reasons of cost.

4.8.2 Solution

Create a self-signed SSL certificate:

For Red Hat:

$ make -f /usr/share/ssl/certs/Makefile filename.crt

For SuSE or other:

$ umask 077
$ openssl req -new -x509 -days 365 -out filename.crt -keyout privkey.pem

4.8.3 Discussion

A certificate is self-signed if its subject and issuer are the same. A self-signed certificate does not depend on any higher, well-known issuing authority for validation, so it will have to be explicitly marked as trusted by your users. For instance, the first time you connect to such a server, client software (such as your web browser) will ask if you would like to trust this certificate in the future.

Self-signing is convenient but runs the risk of man-in-the-middle attacks on the first connection, before the client trusts the certificate. A more secure method is to pre-install this certificate on the client machine in a separate step, and mark it as trusted.

When you create the certificate, you will be prompted for various things, particularly a Common Name. Pay special attention to this, as when creating a certificate signing request (CSR). [Recipe 4.7]

If you need many certificates, this method may be cumbersome, as your users will have to trust each certificate individually. Instead, use openssl to set up your own CA, and issue certificates under it. [Recipe 4.9] This way, you need only add your one CA certificate to your client's trusted caches; any individual service certificates you create afterward will be automatically trusted.

Self-signed certificates are fine for tests and for services not available to the public (i.e., inside a company intranet). For public access, however, use a certificate from a well-known CA. To use a standalone certificate properly, you are somewhat at the mercy of your users, who must be diligent about reading security warnings, verifying the certificate with you, and so forth. They will be tempted to bypass these steps, which is bad for your security and theirs.

4.8.4 See Also

openssl(1).

    [ Team LiB ] Previous Section Next Section