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.

RRHS
  • 123
  • 4

1 Answers1

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.

ecdsa
  • 1,354
  • 7
  • 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 Feb 28 '20 at 10:19
  • Could you clarify what confuses you? – ecdsa Feb 28 '20 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 Feb 28 '20 at 10:33
  • And also, am I right in saying that the there are 2 different certs getting sent from the CA server. One is during the CA cert enrollment and one more is during the local certificate request. "AND WHAT DOES THE CERT ACTUALLY CONTAIN IN BOTH THE STAGES"? I think I may have confused myself in the worst possible way. I just don't understand the flow of this process. Could you please explain it. – RRHS Feb 28 '20 at 10:39
  • No CA certs are issued for the device. They are merely installed in its trust store. The public key of the CA is embedded in its certificate, which are, as described, either downloaded via SCEP, or manually installed. In general (and as I mentioned the diagram is for the general case), CA certificates are installed in the trust stores of operating systems and browsers etc. I thought I explained the flow (first get the CA certificate(s) as trust anchor, then request an end-entity certificate for the device). – ecdsa Feb 28 '20 at 11:03
  • But if the public key of CA is embedded in its certificate, how does the client know that the CA server can be trusted? Isnt the public key the only way to decrypt teh encrypted certificate hash and then inturn verify that the hash is the same as what the client expected or calculated it to be? Does that mean, the public keys are all exchanged(Clients to CA server, CA server to Clients) before any request or negotiation happens? – RRHS Mar 01 '20 at 16:41
  • 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 Mar 02 '20 at 08:21
  • Ill just brief up my understanding. Please let me know if im right or wrong as well. Step1: The Device gets the CA public key through some out-of-band means. Step2: The device installs the CA certificate which is signed using the private key of the CA server. Step3: The device decrypts the signed fingerprint using the public key of the CA obtained through some OOB means and verifies the hash by applying the same hash algo to the cert and then comparing it with the same hence the trust is established. Step4: Request for the End entity certificate. Thanks a lot for the answers. – RRHS Mar 03 '20 at 08:46
  • 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 Mar 03 '20 at 09:18
  • Perfect!! Thanks again for all the quick responses.. – RRHS Mar 06 '20 at 17:58