How to implement a renewed 3rd Party Issuing CA Cert

[Alias]

Hey Mates,

we are using Remote Access VPN (on 80.20) with certificates and we operate our own public key infrastructure (ADCS)

We have been using this for a while and all is/was fine.

However, now the Issuing CA has been renewed because we got to the point where the validity of the CA certificate was less than the validity time of certificates, i.e. the Issuing CA Cert is valid for another 1 1/2 years, some certificates signed by it have a validity of 2 years. So, issued cert validity > ca certificate validity

They used a new key pair for the new certificate and now the new certificate has: CA Version v1.1, a new keypair, but the same CN 

I am wondering, how to get this certificate in the firewall. When I tried to add it, i got an error message that the CN is already in use and that the import failed.

I am not sure, but do I need both?

There are certificates that are signed by the old CA and are still valid for another year. Will these certificates be invalid if I delete the old CA certificate and import the new one?

Do I even need to change something at all?

I am kinda lost here and would highly appreciate input

Cheers,

D

Also, another thing in that direction. Does anybody know in detail how the Gateways check a CRL (e.g. in case the CRL ist hosted internally and externally - where does it go?) or can point me to a resource where it is described?

[PhoneBoy]

Not 100% sure on your first question.
However I believe the main thing as far as validating certificates is the certificate issue date versus the validity dates of the CA that signed it.
That means a CA can theoretically issue certificates that are valid past it’s own validity date provided they are issued before the CA key expiration date.

For your second question, the certificate authority public key contains the precise URL for the CRL, which is accessed by the gateway as part of the certificate validation process.
Don’t know the precise flow here but I imagine it functions like other X.509 certificate validation does.

[Alias]

Hey PhoneBoy,

thank you for your reply.

              However I believe the main thing as far as validating certificates is the certificate issue date versus the validity dates of                  the CA that signed it.

             That means a CA can theoretically issue certificates that are valid past it’s own validity date provided they are issued                       before the CA key expiration date.

I think you are right there. As far as I understood, the certificate will be valid until the point the CA key pair itself expires. The reason for the CA renweal is, that the CA guys want to avoid drama on the expiration date (i.e. all the certs being invalid at once) and therefore renewed the certificate of the issuing CA including a new keypair. 

I played around over the weekend, however if anything it confused me even more. I got myself a new certificate (based on the new keypair which I wasnt able to import so far) and for some reason it works without issue. I dont understand how though. The Checkpoint trusts the CA but now the CA is using another Certificate for itself (same name but different keys, different serial, etc) and it still seems to be trusted.

For the second question, I found some info, that the gateways, mgtmserver, etc cache the CRLs in several locations. We have 2 CRL Deployment Locations in our certificates, one is hosted internally one externally. I would assume that the system checks both locations but I dont know for sure. It would also be interesting to know how the Checkpoint behaves here, such as how often will it fetch a CRL? does it check against the cached CRL? Will the CP realise if a certificate is freshly invalidated?   

EDIT: I just figured sth out. The new certificate for the issuing CA has a field "Previous CA Certificate Hash" which corresponds to the  thumbprint of the original Issuing CA certificate. This would explain why it is still trusted

[PhoneBoy]

Not sure how often it checks, but that should be relatively straightforward to figure out from the logs. 
I do know that for Site-to-Site VPNs anyway that if the CRL is not available for 24 hours, VPNs will stop working. 

[PA]

Hi,
I have the same problem after renewing certificate of the external CA server (Microsoft AD CA)
Some remote clients with versions: E88.10, E88.30 have response "Certificate is badly signed"
but some others client versions, even last E88.70 have response: "cannot complete certificate chain"
Have you finally resolved the problem?

[PhoneBoy]

Did you include the entire certificate chain in the export?
It should include the root CA as well as any intermediates in the same p12 file.

[PA]

There is only root CA, no any intermediate.
The renewed CA certificate has version v1.1, a new keypair, but the same CN
and a field "Previous CA Certificate Hash" which corresponds to the thumbprint of the original Issuing CA certificate.

[PhoneBoy]

Best to involve TAC here if they are not already.