Several years ago (5 to the week) I designed and implemented a PKI infrastructure for enrolling users, enabling them to send secure (i.e. encrypted) S/MIME messages. The nifty bits were that we have an off-site enrollment “agency” that create the private keys which are kept in a safe and a certification authority that does the actual signing. The enrollment agency and the authority transmit signing requests and signed (public) certificates to eachother via custom made XML messages. The whole thing is of course managed in LDAP. All has been well, and both OpenSSL and the pile of code I wrote at the time, have been performing admirably. Just one thing was missing, and that was certificate renewal, which I postponed, because I knew I had plenty of time® to implement that. Time flies… Suddenly, the first announcement of expired certificates arrives. Damn. Ok, no problem: simply renew the certificate, right? OpenSSL forsees that, so I simply start re- issuing the certificates from the original Certificate Signing Requests, which we keep in store; that is easy. No sir. Nothing doing. Upon re-issuing a certificate, it gets a new serial number assigned and the combination of that plus the private key is not sufficient to access S/MIME messages encrypted to the old certificate pair. It took a bit to find, but I managed to create some code which does just that. Actually it is of course documented: if you look carefully at section 6.2 of RFC 3852 the fog lifts. Remember: re-use the serial number, or you are in trouble. :-)

LDAP, Mail, and Security :: 30 Nov 2007 :: e-mail


blog comments powered by Disqus