|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 5
In summary, the client verifies the server's certificate by examining the name on the certificate and determining whether or not it's the name of the server to which it desires to communicate. If the server's certificate has the right name, the client inspects the certificate's signature to determine whether or not it was generated by a CA that it trusts. Authentication is complete.
Again, not quite. In practice the situation proves more complicated. First, it's possible that someone you don't know or trust signed the server certificate, but you have a certificate for this signer that was, in turn, signed by someone you do trust. In practice, these certificate chains can extend several generations. To verify the server certificate, you must verify every certificate in the chain all the way back to a trusted root certificate.
But wait, there's more: Certificates are valid for only a limited period of time. X.509 certificates contain begin and end dates. For the certificate chain to be valid, all certificates in the chain must be within their validity period. Furthermore, as you learned in Part 3, certificates can be revoked. It's therefore necessary to check the appropriate CRLs (certificate revocation lists) for every certificate in the certificate chain.
You're not done yet. Certificates can contain critical extensions, as you learned in Part 2. Although the details aren't well defined, implementations supposedly ensure that restrictions embodied in extensions are
followed when they pertain to certificate validation. For example, the keyUsage extension specifies how to use a certificate: you shouldn't use an encipherment certificate for digital signatures.
Unfortunately, you're still not finished. The IETF PKIX's (Internet Engineering Task Force Public Key Infrastructure X.509 working group) latest draft of the certificate standard, which goes into great depth on certificate chain verification, also requires that the verification process handle policies. Certificate policy terms indicate the policy under which a certificate has been issued and the purposes for which the certificate may be used.
Tired yet? Frankly, I'm about shot. This process requires a lot of work and it's hard to get it right. Later I'll talk about some efforts under development that will alleviate some of the difficulty. Right now I want to give you some code to play with that completes a subset of the steps above, but enough to provide accurate and useful certificate chain verification.
If you toss out policies, extensions, and CRLs, a manageable set of operations remains for you to work with. Precedent indicates that you can sometimes leave these pieces out. SSL, the X.509 killer app available in nearly every browser in existence, doesn't perform any of those operations.
Here are the steps to verify an X.509 certificate chain:
The following code performs these operations for a certificate against a certificate chain: