12
$\begingroup$

I am new to cryptography and I want to know the details of how a Certificate Authority issues a digital certificate.

From what I know (please correct me if I'm wrong at any parts of my explanation):

If Alice wants to request a digital certificate, Alice will send her public key to the Certificate Authority.

The Certificate Authority will then check whether the public key sent by Alice is legitimate, and will generate a digital certificate using the Certificate Authority's private key to sign Alice's public key.

Now, if Bob wants to communicate with Alice, Bob will get Alice's digital certificate to confirm Alice's identity. If Bob confirm the recipient is really Alice, he will then encrypt his message with Alice's digital signature public key and Alice will decrypt the message with her private key.

Three questions came into my mind:

  • Does Alice sends only her public key to request a certificate from the Certificate Authority?

  • How does the Certificate Authority prove that the public key is
    legitimate and belongs to Alice, since the Certificate Authority does not know Alice as well?

  • What are the things that a Certificate Authority checks for before
    issuing a digital certificate to a person?

$\endgroup$
0

2 Answers 2

7
$\begingroup$

Great question. I'll answer it in several parts.

Which Keys does Alice send?

There are two cryptographic operations that Alice may want to do: encryption/decryption, and signing/validation. You can either use the same keypair for both, or have two separate pairs of keys.

1 keypair method:

Here Alice would sign outgoing messages, and decrypt incoming messages with the same private key. Bob would validate the signature on her outgoing messages, and encrypt messages for her using the same public key.

2 keypair method:

Here Alice would have a (signing_private_key, validation_public_key) keypair, and a separate (decryption_private_key, encryption_public_key) keypair.

In both cases she only sends the public keys to the Certificate Authority (CA) to be made into certificates. The private keys are private, she never shares them, they never leave her machine, they never become certificates.

How does the Certificate Authority (CA) trust Alice?

There are several trust models that different organizations use. Many large companies / government departments operate their own CAs for internal email, file storage, etc. In these cases when someone is hired they are issued digital certificates along with their ID badge, parking permit, etc. We trust that Alice is who she claims to be because she's sitting right in front of the Security Officer issuing the ID.

For web certificates like SSL establishing trust is little more complicated. The CA/Browser Forum has guidelines for CAs on how to verify the identity of applicants. Here is a long list of guidelines. The common forms that most CAs offer are Domain Validated (DV) and Extended Validation (EV) SSL certificates.

Domain Validated (DV) certs

This basically asks you for an email address and a person's name along with the web domain that you want a cert for. It does a whois lookup on the domain to make sure that the name and email you provided matched the domain's registration information. Additionally they can send a confirmation to the email address to make sure that you control it. DV certs can be completely automated, and in fact, "On November 18, 2014, a group of companies and nonprofit organizations, including the Electronic Frontier Foundation, Mozilla, Cisco, and Akamai, announced "Let's Encrypt", a new nonprofit certificate authority that plans to provide free TLS certificates" (wikipedia).

Extended Validation (EV)

The CA/Browser Forum specifies criteria for issuing EV certs, these all require a human in the loop, and relate to how stringently the identity of the applicant organization is researched. Having a phone call between the CA and the applicant is a basic requirement. Often documents are signed, and a face-to-face meeting can even be required before the CA will issue an EV cert. The level of validation that was performed will be included in the certificate to increase its public trustworthiness, consequently issuing CAs charge more for higher quality EV certs.

Many issuers also offer variations on the SSL cert wich don't fall into either the DV or EV categories. For example GlobalSign also offers Organization Validation (OV) as an intermediate category. Entrust offers many different types of certs depending on the network structure and software systems being used by the applicant.

$\endgroup$
0
4
$\begingroup$
  1. Alice sends a CSR (certificate signing request) to the CA, which contains her public key, her name and usually her location. This CSR is then signed to prove ownership of the associated private key. The CA uses the data in the CSR to derive a certificate which will be handed to the user afterwards. The user can then prove his identity.
  2. The CA needs to "know" Alice. Usually this is done by setting up an account, verifiying personal data in the context of this account and putting the CSR in the context of the (verified) account.
  3. They'll always check if the CSR matches (roughly) with the data you gave them with your account. Concerning other validation there are different levels.
    Level 1: simple validation.
    You give the CA an e-mail adress and it sends you a verification code which you have to enter in your browser. (for S/MIME) Or the CA sends a mail to a box of "your" domain (like postmaster or the whois adress) and checks your ownership this way.
    Level 2: personal validation
    Usually this requires some official docuents which you'll send the CA (as a copy). For companies this means some tax documents or such things.
    Level 3: extended validation
    This means multiple documents (mainly tax stuff)
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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