4

On a Juniper Firewall, the command show security pki local-certificate will give all sorts of detail for a local certificate. (The sort of certificate you would use to stand up an IKE connection)

My question is, is there an equivalent command for the certificate being used by the remote peer to validate themselves?

Or, is the remote peer's certificate also considered by Juniper to be a 'local certificate', even though it's for the remote peer?

I can see that there is a command 'show security ike active-peer' that can be used to get the security associate details.

And that there's a command show security ipsec security-associations that gives a lot of details, but not, it appears, the details of the remote certificate (I don't have access to enough equipment to check for myself, I'm afraid)

The page IKE Policy for Digital Certificates on an ES PIC suggests that it's possible to assign a name to the remote certificate.

To define the remote certificate name, include the identity statement at the [edit security ike policy ike-peer-address] hierarchy level:

[edit security ike policy ike-peer-address]

identity identity-name;

It's not clear to me if that name can then be used in the same way that the name of a locally stored certificate can be.

Juniper's introduction to PKI does talk about a "Remote server local certificate", which suggests that maybe for some purposes, local doesn't strictly mean local but also includes "remote local certificates". (Odd concept.)

1
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Commented Dec 16, 2020 at 23:53

1 Answer 1

3

The short answer is no:

My question is, is there an equivalent command for the certificate being used by the remote peer to validate themselves?

The only options for viewing remote certificate information is show security ike active-peer [detail] and show security ike security-associations <peer-ip> detail. These will provide you with the Subject string of the remote certificate, but not a lot else (no validity information etc.)

Or, is the remote peer's certificate also considered by Juniper to be a 'local certificate', even though it's for the remote peer?

No, local-certificate only refers to the cert that is loaded on the device you are connected to, and is distinct from ca-certificate; the Certificate Authority chain/cert you will also have loaded on each node to validate local-certificate and remote certificates presented to this node.

The page IKE Policy for Digital Certificates on an ES PIC suggests that it's possible to assign a name to the remote certificate.

I've not seen the identity on an ES PIC before, but I would imagine that it refers to the Subject or CN of the remote certificate.

What is the problem you are trying to solve?

3
  • "What is the problem you are trying to solve?" We were testing what happens to an established tunnel when a certificate is revoked. We were expecting to see the tunnel go down, after a delay. And it wasn't going down, so we were trying to work out why not. One theory was a problem with the CRL. Another theory was that we had the wrong certificate, somehow. Turns out, the Juniper default is to not reauthenticate existing tunnels. We set reauth-frequency >0 and got the behaviour we expected, so the main mystery is solved. Commented Dec 4, 2019 at 0:08
  • ahh yes, we recently discovered this ourselves but with certs expiring rather than being revoked - the certificate exchange only happens when the tunnel is renegotiated at session expiry, so we had a bunch all failing several hours apart but from expired certs all generated at the same time Commented Dec 5, 2019 at 11:17
  • Yes, that's the behaviour we were expecting to see - tunnels failing some time in the following 24 hours. When that didn't happen, we needed to know why. (Kudos for looking for the XY_problem) Commented Dec 5, 2019 at 21:59

Your Answer

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

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