CA certificate and Local certificate

Question

There is something which is bothering me when i think about the CA cert and Local cert.

Below are my queries which pertains to juniper but may be generic as well.

1) "request security pki ca-certificate enroll ca-profile ROOT2" The above is used to get the CA certificate from the CA server if I am not wrong. And the same(certificate) is used to confirm that its indeed a trusted CA server. But what does the cert actually contain? How does the device know that its the intended CA server?

The above diagram shows how the Recipient receives the Cert and decrypts it using the CA's public key. But how does the Recipient know about the public key and the Hash algorithm?

->Is that negotiated separately before all this happens?

-> And does that happen in clear-text?

->And also, is it a one time thing, as in is the CA cert loaded onto the router and is used only once to just authenticate the CA server or is it used again during any time of the traffic flow between the IPSec peers?

2) "request security pki local-certificate enroll certificate-id"

In the above step, the VPN peer is requesting for a local cert.

->So, is it during this step that the CA server gets to know about the peer's public key or is it exchanged well in advance?

-> And does the above diagram hold good for the local cert as well? In this case, the cert contains the peer's public key and other info such as subject, etc and does it hash it to create a "fingerprint/digest" and again encrypts it with its private key?

-> And if the above process is correct, then do the peers again check the local cert's integrity and authenticity by decrypting using the CA's public key and then only sending it to the other peer ? If not, does it directly send the received local cert to the peer?

I couldnt get the answers for the questions asked above.

Please help me understand the same. Thanks a lot in advance.

Answer 1

First, the diagram you posted just shows the general process of a CA issuing a certificate (by signing a hash of the certificate's contents with its private key), and a client verifying that a certificate is issued by a specific CA (by verifying the signature using the CA certificate's public key). For this to work, the client has to trust that particular CA (or at least the root of a multi-level PKI), i.e. it has to be in possession of its certificate beforehand.

This is only generally related to the Simple Certificate Enrollment Protocol (SCEP), which the mentioned commands on Junos OS use.

As you mentioned, request security pki ca-certificate enroll ... requests the CA certificate(s) from a SCEP server. The device does not trust these certificates automatically. Instead, the command prints the subject distinguished names (DN) and fingerprints (hashes of the public key) of these certificates and it's up to the user to verify and confirm them. According to the documentation this could look something like this:

user@host> 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

An alternative to using that command is request security pki ca-certificate load ..., which will load the CA certificates from a file (i.e. not via SCEP).

After the CA certificates are installed and trusted, they can be used to request end-entity certificates via SCEP. The command request security pki local-certificate enroll ... does exactly that. It will create a public key pair and generate a certificate request, which contains the client's public key and subject DN and e.g. certain extensions like subjectAlernativeNames. It may also contain a challenge password if the CA requires it. That PKCS#10 request is encrypted with the CA's public key (or in certain cases the challenge password) and sent via SCEP to the server. There the CA verifies the request and, if accepted, issues a certificate, which is then returned via SCEP to the client.