IssueTracker

Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.

Problem you have encountered:

-After a recent migration from using EJBCA public CA, a month ago, the core issue arises because the certificates being issued from GCP have a "ValidFrom" time that matches the exact current time of issuance/request.

In environments where there may be even slight time drift (a few seconds or minutes) between the client device and the CA (Certificate Authority), the certificate is perceived as not yet valid by the client.


When you request a certificate from a CA such as DigiCert, the certificate Valid From time is 'backdated' to the start of the day of the validity period. i.e if a Certificate is requested on 13th, the ValidFrom time is the start of day of the 13th (00:00h) and not the time of the request or when the certificate was issued by the CA.

Let's Encrypt CA allows an automatic 1 hour backdate of the timestamp from time of issuance.


What you expected to happen:

-When this is done for GCP Certificate Authority Service, the 'ValidFrom' time for the resultant certificate received shows instead the time of request / issuance which does not work well for Timezone difference, as you are likely to get an error-  `A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file`

We would like to understand why this is happening? The request is if the GCP team can change this behaviour by backdating the setting of the Valid From time to Start of day at least.


Steps to reproduce:

-By following the documentation - https://cloud.google.com/certificate-authority-service/docs/requesting-certificates , you can create a certificate request and generate the certificate.

Once done, check the certificate details and you will note that the ValidFrom timestamps comes up as the time of request.


Other information (workarounds you have tried, documentation consulted, etc):

There are no workarounds for the issue at the moment.