0

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?

enter image description here

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.

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
10
  • I understood the 2nd part related to the local certificate. But i still have some confusions.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
    – RRHS
    Commented Feb 28, 2020 at 10:19
  • Could you clarify what confuses you?
    – ecdsa
    Commented Feb 28, 2020 at 10:25
  • "First, the diagram you posted just shows the general process of a CA issuing a certificate" --> Does that mean, the process is the same for the local cert enrollment and the CA cert issue for the Devices? "and a client verifying that a certificate is issued by a specific CA (by verifying the signature using the CA certificate's public key" --> When and how does the device receive the public key of the CA server? "it has to be in possession of its certificate beforehand." --> How does the device get its. cert before hand as thats what is being requested in the first place.
    – RRHS
    Commented Feb 28, 2020 at 10:33
  • 1
    As I said in my answer, it's up to the device admin that installs the CA certificates to verify they are correct and can therefore be trusted (e.g. by comparing the fingerprints of the public keys with those provided out-of-band by the CA maintainers, or by manually installing the already verified CA certificates). The CA certificates (in particular the root CA) are the trust anchors and this trust has to be established manually before end-entity certificates can be issued or even verified.
    – ecdsa
    Commented Mar 2, 2020 at 8:21
  • 1
    Step1/Step2 can be combined by using the first command (which fetches the certificates via SCEP and installs them) if the fingerprints can be verified somehow. The root CA certificate is self-signed by the associated private key, intermediate CA certificate are signed by the issuing CA (basically like end-entity certificates). Step3: No decryption is involved when comparing fingerprints, these are simple hashes (usually SHA-1) of the public keys contained in the certificates. Decryption is required to verify signatures in the certificates themselves (i.e. to verify the certificate chain).
    – ecdsa
    Commented Mar 3, 2020 at 9:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .