You must care about three configurationfiles and -directories
etc/openssl/openssl.cnf
,
etc/openssl/openssl
and
etc/openssl/extfiles
. The first file contains the
configuration for the CA. This means the file is used for the generation
of the initial CA-CSR, the selfsigned certificate (if you setup a Root
CA) and the CRLs. The file is configured fullautomatically during the
installation but if you are setting up a serious CA then you should check
this file too. The directory etc/openssl/openssl
contains the configuration for the different roles except of the
extensions. The relevant things which you must compare with your policy
are the lifetime of the certificate and the algorithm which is used to
sign the certs. The dircetory etc/openssl/extfiles
contains the definitions of the extension. Please check these files
carefully.
[[RFC3280] The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign the certificate. This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). ]
The authority key identifier is used for path construction. Only if you create a self-signed root CA certificate then you only need the subject key identifier. You can use the subject key identifier of the CA certificate or/and the issuer's certificate serial and issuer name. It is recommended to use both. It is important to understand that the name is the name of the issuer of the CA certificate. If you have a root CA, a sub CA and a user certificate then the name in the authority key identifier is the subject of the root CA's certificate.
The value should look like this:
Example 4.16. OpenSSL configuration - Authority Key Identifier
authorityKeyIdentifier=keyid,issuer:always
Never mark this extension as critical.
The different names of HTTPS servers are one of the most problematic things in the todays world. Like for many other cryptographic issues in the web there is a standard for servercertificates - RFC 2818 “HTTP over TLS”.
The standard defines that you have to check the subject alternative name for an appropriate entry (DNS or IP see RFC 2459). If this search fails then check the common name in the distinguished name of the certificate.
If you use Microsofts Internet Explorer then you have no problems. The IE is full standard compliant. The problem is Netscape. They use the common name like a regular expression in Unix. The common name can be in the format “(server1|server2).my_domain.org”. The clever ones would argue now that we must simply set the subject alternative name like defined by RFC 2818 and set a normal common name because the subject alternative is checked first. This is a nice idea but Netscape ignores the subject alternative name if it checks the name of the server versus the content of the certificate.
The solution is a mix between RFC 2818 and Netscape behaviour. You must set the common name in the distinguished name like Netscape defines it. After this you must set all DNS-names and the IPs of the server in the subject alternative name. If you do this then all standard compliant browsers will evaluate the subject alternative name first and will ignore the common name in the distinguished name. So the certificate is standard compliant but supports the cruel behaviour of Netscape too.
Before you think this is a perfect solution then please think about aliases. My personal record are 20 different names for one computer which I have to code in a common name. If you think that it is easy then please remember that a common name can only be 64 characters long.
Mailservers usually include SMTP daemons. SMTP servers act as server and client because they work in a hierarchy. Some server softwares like sendmail require that the SMTP server identifies itself as a SMTP client if it contacts another SMTP server. Usually you only want to issue one certificate per server and not one certificate per service and therefore you have to set the extensions for SSL Client and SSL Server like recommended by OpenSSL (please see "man x509" after you installed OpenSSL). If you use sendmail then you can create a server certificate for the SMTP server and an additional client certificate. Sendmail supports two certificates per server or better per daemon.
SSL Client requires the following extensions:
Example 4.17. Minimal SSL client extensions
keyUsage = digitalSignature extendedKeyUsage = clientAuth nsCertType = client
SSL Server requires the following extensions:
Example 4.18. Minimal SSL server extensions
keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, msSGC, nsSGC nsCertType = server
msSGC and nsSGC mean Server Gated Crypto from Microsoft and Netscape.
If you want to configure only one certificate per SMTP server then you have to issue certificates which looks like a christmas tree. They have to include all extensions for clients and servers. A configuration can look like this:
Example 4.19. Minimal SMTP extensions for a single certificate
keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth, msSGC, nsSGC nsCertType = client, server
If you want to use OpenCA with F-Secure VPN+ then you should bear in
mind that this software can only download a CRL via http or ldap.
They don't support https and ldaps. This is important if you
configure your CRLDistributionPoints in
OPENCADIR/etc/openssl/extfiles/*.ext
. You can
easily fix this problem by using LDAP for CRL-distribution.
Certificates for VPN+ Gateways and Machine certificates should include the DNS name and IP address in the subject alternative name. The certificates for the persons to authenticate them can be contain anything you want. It must only be valid client certificates.