Certificates(CA certificate and EE/Local certiificate)

Question

There is a small confusion related to CA certificate and Local certificate. I had asked a similar question before. This time, its a little specific.

For authentication using PKI, below are the steps.

--> Get the CA certificate and load it onto the device.

-->Generate a private and public key pair

-->Request for a local/EE certificate.

Now, the steps followed for those are:

Step1:request security pki ca-certificate enroll ca-profile entrust

Received following certificates: Certificate: C=us, O=juniper, CN=First Officer Fingerprint: 46:71:15:34:f0:a6:41:76:65:81:33:4f:68:47:c4:df:78:b8:e3:3f Certificate: C=us, O=juniper, CN=First Officer Fingerprint: bc:78:87:9b:a7:91:13:20:71:db:ac:b5:56:71:42:ad:1a:b6:46:17 Certificate: C=us, O=juniper Fingerprint: 00:8e:6f:58:dd:68:bf:25:0a:e3:f9:17:70:d6:61:f3:53:a7:79:10 Do you want to load the above CA certificate ?

[yes,no] (no) yes

Question: Once the device gets the CA certificate from the CA server, how does the device verify that its the right server from the fingerprint?

Does saying yes on prompt automatically means that Im trusting the certificate and Ive verified the fingerprint through some OOB means?

And also, the Hashing and encryption is done for the whole certificate content or just the public key of the CA server?

Step2: user@host> request security pki local-certificate enroll certificate-id

In this step, we request for the local-certificate after we generate the key-pair.

Question: Once we obtain the local-certificate from the server, how do we verify that its from the right source or server and authenticity of it?

Is there any signature decryption done? Or does it trust it because we have configured that server under the ca-profile?

Even if it decrypts it, does the device do it that quick? And also, does all the decryption and comparison has to be done manually by a human?

Step3: Lets say a tunnel has to be formed between A and B. A sends the local-certificate to B and B sends it to A.

If Im not wrong, the local-certs contains their respective public keys.

user@host> show security pki local-certificate certificate-id hello detail

Certificate identifier: hello

..... Issuer: Common name: Example-CA, Domain component: local, Domain component: demo Subject: Organization: o1, Organization: o2, Organizational unit: ou1, Organizational unit: ou2, Country: US, State: CA, Locality: Sunnyvale, Common name: cn1, Common name: cn2, Domain component: dc1, Domain component: dc2 Subject string: C=Example, DC=dc1, DC=dc2, ST=CA, L=Sunnyvale, O=o1, O=o2, OU=ou1, OU=ou2, CN=cn1, CN=cn2 Alternate subject: "[email protected]", user.example.net, 192.0.2.1

Validity: .......

Public key algorithm: rsaEncryption(1024 bits) 30:81:89:02:81:81:00:b4:14:01:d5:4f:79:87:d5:bb:e6:5e:c1:14

..

Signature algorithm: sha1WithRSAEncryption

Distribution CRL:

http://example.example.net/CertEnroll/Example-CA.crl

Use for key: Key encipherment, Digital signature, 1.3.6.1.5.5.8.2.2, 1.3.6.1.5.5.8.2.2

Fingerprint: 76:a8:5f:65:b4:bf:bd:10:d8:56:82:65:ff:0d:04:3a:a5:e9:41:dd (sha1) 8f:99:a4:15:98:10:4b:b6:1a:3d:81:13:93:2a:ac:e7 (md5)

Above example shows a local-certificate, and lets say B receives it from A.

How does, B authenticate the certificate? Or how does it know that it has come from A?

I know there is a signature verification done, but what is decrypted and what is compared to prove that the peer authentiicity.

I have gone through documents, but it has not provided me with a clear picture, so I have come here for the answers.

Thank you.

Answer 1

Does saying yes on prompt automatically means that Im trusting the certificate and Ive verified the fingerprint through some OOB means?

Correct, so it's the user's responsibility to verify that these are the correct certificates.

And also, the Hashing and encryption is done for the whole certificate content or just the public key of the CA server?

It's definitely possible that the complete certificate is hashed. Other options are to only hash the subjectPublicKeyInfo ASN.1 structure in the certificate, or only the subjectPublicKey inside that (i.e. the public key with or without algorithm identifier).

Once we obtain the local-certificate from the server, how do we verify that its from the right source or server and authenticity of it?

The Simple Certificate Enrollment Protocol (SCEP) ensures that using the trusted certificates installed in the first step. This involves encrypting the certificate request for the CA and verifying the signature after the certificate is returned. All this is completely automated and requires no user intervention.

How does, B authenticate the certificate? Or how does it know that it has come from A?

It has to trust the CA that issued the certificate. And it uses the identity (e.g. the subject DN or a subjectAltName, e.g. a FQDN or an IP address) to verify it is the correct host.

I know there is a signature verification done, but what is decrypted and what is compared to prove that the peer authentiicity.

There are several aspects to this. Host A will provide a signature with its private key as part of the the authentication protocol (e.g. TLS or IKE), which B verifies with the certificate received from A (basically the signature is decrypted and the data is compared to locally produced authentication data). The second aspect is verifying that the received certificate is trusted. For that B builds a trust chain to a trusted CA certificate and the signatures in that chain are verified. And as mentioned above, the identity of host A also has to be confirmed by the received certificate.

Answer 2

@ecdsa gave a great answer, I'll try to answer in a different way.

---

Question: Once the device gets the CA certificate from the CA server, how does the device verify that its the right server from the fingerprint?

Does saying yes on prompt automatically means that Im trusting the certificate and Ive verified the fingerprint through some OOB means?

And also, the Hashing and encryption is done for the whole certificate content or just the public key of the CA server?

Short answer: it doesn't have any way to validate it; you are telling your machine to trust this CA.

Let me get philosophical for a minute; digital security is a stack of turtles, but at the bottom you have to trust someone. For example there's lots of security mechanisms in my Android phone, but at the end of the day I need to trust the software developers writing the OS and the engineers designing the hardware to not insert backdoors.

The core idea of PKI is to make this "stack of turtles" clear and transparent. You, as the user, tell your computer "I trust this root CA". This is referred to as a "trust anchor". The root CA will be used to verify the trustworthiness of other cryptographic objects and entities, but your computer has no way to test the trustworthiness of the root CA itself. It is the bottom turtle.

Before you load in the root CA cert, you need to be sure you have the right one. The best way is to manually (with your own eyes) compare the cert fingerprint (which is a hash over the whole certificate content) against an independent trusted source (for example compare the cert file you have against the root CA fingerprint on the vendor website, or get a support person to read you the fingerprint over the phone, etc).

---

Question: Once we obtain the local-certificate from the server, how do we verify that its from the right source or server and authenticity of it?

You are quoting some command-line output from your software, but you haven't told us what software that is. The answer to this question will depend on what software you're using and how it's configured.

Analogy: when you get a new driver's license card, you send your photo and signature off to the government and a card comes back in the mail. You should check that the photo and signature are yours (the "is this me?" check), but typically you won't bother to check that the card is authentic from your government. The police officer who pulls you over will check the card's authenticity, but typically you as the card holder won't.

When you get a new certificate, you send your public key (inside a CSR file (Certificate Signing Request)), and you will get a full certificate back. Your software should check that the public key in the cert matches the private key that it kept locally (the "is this me?" check), but typically it doesn't need to check that the cert properly chains to a trusted root CA. Your specific software may do this check, but in general a machine does not need to know who it's CA is; for example you can configure IIS to serve a given TLS cert without needing to tell IIS about the root CA that issued it. The web browser connecting to your site will certainly check that the cert chains to a root that the browser trusts, but it doesn't really matter to you.

If it's important to you to double-check that the CA issue the cert properly, and that it came from the CA you expected, I suggest that you verify this manually using openssl x509 commands.

---

The last set of questions you ask are about how digital signatures work. This is worth a second question since it is a large topic by itself.

We have a canonical answer about how TLS works and how it uses certificates, I refer you to that thread for further reading. You haven't told us whether your software is using TLS or some other crypto protocol, but if you understand TLS, the others are all similar.

• How does SSL/TLS work?