7

I think I might understand this stuff, but I want to be sure I've got the details correct. There is a lot of information out there on the high-level implementation of certificates, as well as the math-level implementation of encryption and such, but I haven't found very much on the low-level details.

I've written up my understanding, as best I can piece it together, but I'm sure I've goofed up details in some way or other. Can you tell me what those errors are? (And I don't mean what I've left out. I do not want to discuss CRLs or X.509 formats, etc. All that is implementation. What I care about is a semi-idealized understanding of the process.) Here's my write-up.

Thanks in advance.

Getting a certificate from a CA

A certificate authority (CA) is just an organization that has a public-private key pair and which others trust to verify identities. If Alice (alice.com) wants to have a digital certificate signed by a CA, she generates a public-private key pair. She creates a document containing some identifying information such as the FQDN and a person’s email address, etc., and encrypts it with her private key. She packages this encrypted document with her public key. This is the certificate signing request (CSR).

She sends the CSR to the CA and asks for them to verify her identity. They use the public key to decrypt her document, proving to them that she holds both the public and private keys in that pair. They may verify her identity in various ways, from automated and technical, to lengthy and legal, depending on what the purpose of the certificate is (authenticate an email address? A web server?), whether it’s for an individual or a business, and what level of trust they want others to place in the certificate.

Once the CA has verified the identity of the applicant, then they will create a document containing her identifying information (may or may not be identical to what she submitted), together with her public key, and will “sign” that document by creating a hash of it and encrypting that hash with their private key. The signature and some metadata (e.g., which CA generated it) are tacked onto the document, and the result is her certificate.

Verifying a certificate

Suppose Bob wants to verify Alice is who she claims to be. She supplies her certificate to him, and he determines which CA generated the certificate. Because he trusts the CA, he has their public key stored on his system. He can use the CA’s public key to check the signature: He decrypts the hash with the CA’s public key, and calculates the hash himself as well. If the values agree, then he knows that the document has not been tampered with, and that the CA vouches for Alice’s identity.

Using an intermediate CA

It is possible to have an intermediate CA. In this case, the intermediate CA’s certificate issues the user’s certificate, and it has its own certificate signed by a higher-level CA. For the user’s certificate to be trusted by others, the chain of signing must end up with a trusted root CA.

1

Your writeup checks out. One nit:

As dave_thompson_085 mentions, encrypting and signing are not the same operations. Although they may be implemented in the same manner in textbook RSA, does not mean they are the same. Indeed, X.509 supports ECDSA, where signatures are implemented entirely different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.