4. Certificate Issues

This section consists of two big groups of problems - CDPs and application specific problems. Applications are also discussed in other sections of the OpenCA guide in case we have developed special configurations to solve the problem.

4.1. CDPs

CRL Distribution Points are a critical area. There were several PKIs in the earlier years which had no CDPs or only one CDP. Secure applications must verify the state of a used certificate. Such applications check the CDP field in the extensions of a certificate to find a usable verification source. Today a CRL Distribution Point should not be a source for a CRL. It can be an OCSP responder. A CDP is today more of a Certificate Status Point.

The first question is which protocols must be supported. The common protocols LDAP and HTTP should be supported always. HTTP is supported by nearly all devices but some devices prefer LDAP over HTTP - especially some network solutions. Additionally there are OCSP and HTTPS. OCSP is a protocol to verify the state of a single certificate. This protocol has a much better performance for slow network interconnects if you have large installations with many (revoked) certificates. HTTPS supports you with a trusted source, but is a trusted source necessary for CRLs? Usually not but sometimes yes. CRLs are signed by the CA and they have period of validity. There is only one working attack for CRLs. If a certificate was revoked, but the old CRL is still valid and if the CDP uses HTTP, then an attacker could present the user the old CRL. So this attack is more a question of security policy than a technical question. The validity period is a policy question too because most applications don't accept CRLs if the timestamp for the next update is over. The cool thing is that a CRL is never invalid! There can only be a newer CRL but as mentioned earlier this is more a political discussion.

The second question is how many physical CDPs do you need. If you design a scalable infrastructure then you must be able to tolerate service interruptions of several components like cables, routers, switches and servers. It is a really good idea to always have a local CDP if you only have a single interconnect to your central network. However not every branch office needs its own CDP, since if their computers (including their file and mail systems) are offline then it is not necessary to have a CDP online.

The third question is tricky. Which order should the CDPs have? The question is interesting in the case of network outages. If you support LDAP and HTTP, you have three servers which all serve both protocols. The CDP are ordered like the servers and servers one and two are not available because of a more or less big digger then your applications waits for four timeouts until it can access the first CDP successfully. The application has to wait for timeouts from LDAP on server one, HTTP on server one, LDAP on server two and HTTP on server three. So it is a really good idea to mix the order of protocols and servers. This is most important for application which understand many protocols. Stupid alphabetical ordering using the DNS names is not recommended. Do you think a user would wait two minutes per recipient of an email, for verification if he wants to send a commit for a meeting?

The last question often, does not have a complete solution today. Can some supported and necessary protocols crash other applications? If you use HTTPS then you should invest some time on this problem because it is a typical chicken and egg problem. If you have Microsoft client and the client tries to verify the certificate status via a HTTPS CDP then it receives a certificate from the HTTPS server. This certificate must be verified. If the certificate is from the same CA then the client would contact the HTTPS CDP again to verify the certificate and the verification problem would start again. This is a nice method to implement a busy wait. The only solution is to get a server certificate from another authority which use no CDPs or at minimum no HTTPS CDPs. The insight is that you should be really careful with the usage of crypto protected CDPs.

4.2. Application specific problems

4.2.1. Mail servers

If you start thinking about email security then the starting point is S/MIME or PGP. However at times ethereal admins just use IMAPS and POPS. So far so good. Later they think about server based security and try to implement SMTP over TLS. Certificates issued by OpenCA can be used for SMTP over TLS because the certificates can act both as a client and a server certificate. If you use some other software than OpenCA, or you create a new role for such servers then you should read the documentation of your SMTP server really carefully.

A SMTP server can use two methods for SMTP over TLS. It can use a single certificate which includes the extensions for TLS client and servers, or it can use two certificates - one client and one server certificate. Please read the specs for the certificates carefully and then read specifications for TLS clients and TLS servers. If the SMTP server reports an error after start tls then there is usually a missing extension or a problem with the certificate chain. See Section 3.2.2, “SMTP server”.

4.2.2. Netscape clients

Old Netscape clients do not conform with RFC standards. They use the common name as a regexp to match the server name and ignore the subject alternative name completely. A workaround is described in the configuration area of OpenSSL (see Section 3.2.1, “HTTPS server”).

4.2.3. OpenLDAP

OpenLDAP is an open source software but it's TLS implementation is not the best one. It doesn't check the subject alternative name first, instead it checks the common name of the subject to match the DNS name or IP address. This fails if the certificate subject includes a regexp for old Netscape clients. Two non-standard compliant software packages collide here. Netscape needs regular expressions, OpenLDAP does not support regular expressions and both software packages do not check the subject alternative name first. So it's your job to make a trade-off, or to use Mozilla!