4. Certificate Issues

Today this section consists of two big groups of problems - CDPs and application specific problems. First we discuss all the CDP stuff and second we discuss the different applications. Several applications are discussed in the other OpenCA guides too if we developed special configurations to solve the problem.

4.1. CDPs

CRL Distribution Points are a critical area. THere were several PKIs in the first years which have 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 has not to be a source for a CRL. It can be an OCSP responder too. A CDP is today more a Certificate Status Point.

The first question is which protocols must be supported. The common procols LDAP and HTTP should be supported always. HTTP is supported by nearly all devices but some devices like LDAP more than HTTP - especially some network solutions. Additionally there are OCSP and HTTP. 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 no but sometimes yes. CRLs are signed by the CA and they have period of validity. There is only one working attack. If a certificate was revoked, the old CRL is still valid and 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 the most application don't accept CRLs if the timestamp for the next update is over. The cool aspect is the fact that a CRL is never invalid. There can only be a newer CRL but like mentioned 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 compontents like cables, routers, switches and servers. It is a really good idea to have always a local CDP if you have only a single interconnect to your central network but otherwise not every branch office need it's own CDP because if there computers including their file and mail systems are offline then it is not necessary to have a CDP online.

The third question is a really trickey one. 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 server one and two are not available because of a more or less big digger then your applications waits for four timouts 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 or do you think a user waits two minutes for the verification of every recipient of an email if he wants to send a commit for a meeting?

The last question is today often a not hundert percent solvable problem. Can a supported and necessary protocol crash other applications? If you use HTTPS then you should invest some time on this problem because it is a typical hen 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 contact the HTTPS CDP again to verify the certificate and the verification problem starts 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. Mailservers

If you start thinking about emailsecurity then the starting point is S/MIME or PGP but sometimes the admin know ethereal and they continue with IMAPS and POPS. So far so good. Later they think about server based security and try to implement SMTP over TLS. OpenCA issues certificates which can be used for SMTP over TLS because the certificates act as client and server certificates. If you use other software than OpenCA or you create a new role for such servers then you should read the documentation of your SMPT server really carefully.

A SMTP server can use two methods for SMTP over TLS. It can use one 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 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 are not conform with the RFC standards. They use the common name as a regex to match the servername. They 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. First it checks the common name of the subject to match the DNS name or IP address. This fails of course if the certificate subject inlcudes a regex for old Netscape clients. Two non standard compliant softwares collidate here. Netscape needs regular expressions, OpenLDAP don't support regular expressions and both softwares doesn't check the subject alternative name first. So it's your job to made a tradeoff or to use Mozilla.