Certificate Validity Period Best Practice and other Key Guidelines

– Certificate Validity Period Best Practice –

However, if you are concerned about the Certificate Validity Period Best Practice, this article should interest you. A certificate has a set time of validity.

Also, this comprises a start date and time. And an end date and time. Also, an issued certificate’s validity period cannot be changed after certificate issuance.

However, in this article, you shall learn about top practices that deal with the certificate validity period. Thus, pay attention as we guide you through.

Recommended Strategy

The recommended strategy for determining certificate validity periods is to start with the certificates issued to users, computers, services, or network devices by issuing CAs.

However, the main point to remember is that a CA should not issue a certificate that exceeds the remaining lifetime on the CA certificate.

Though allowed by the standards, note. This scenario can lead to certificates with remaining validity periods expiring.

The above happens when the issuing CA’s certificate expires. Thus, ensure that the CA has enough remaining lifetime on its certificate to issue certificates with the required validity periods.

Certificate Validity Period Best Practice Good Rule

Make the CA certificate validity period at least twice as long as the maximum validity period of any CA-issued certificates.

However, note. To ensure that the remaining validity period of the policy/issuing CA does not affect the validity period of the issued certificates, you must double the validity period value of the policy/issuing CA to 10 years.

To doubling the validity period, note. You can also follow best practices and ensure that the CA renews its CA certificate value at half of the remaining validity period.

Likewise, the validity period of the root CA certificate should be double the validity period of

READ ALSO!!!

Amazing Guide on Certificate Validity Period

Below are some amazing steps on certificate validity period best practices:

1. Limit the Validity Period

Do not issue certificates for long time periods, renew them often. This is similar to renewing passwords. And it helps limit the damage from any potentially compromised key.

Also, the process to refresh keys/certificates must be fully automated.

Otherwise, a frequent renewal cycle will not be practical. Many organisations issue internal certificates for 12 or 24 months simply because they have manual and laborious processes to install new certificates.

This creates a substantial security risk.

However, should a certificate/key get compromised, note? A perpetrator could use it for a long time. A certificate revocation/OCSP process can help to mitigate this.

However, unfortunately, CRL/OCSP is rarely implemented for internal CAs.

2. Implement Validation/Revocation Mechanism

Implement a mechanism to quickly revoke/invalidate certificates. This could be done via OCSP/OCSP stapling, although it requires implementing an internal CA/OCSP responder.

Certificate revocation/CLR can work as well in the internal setting if properly configured. If there no OCSP/revocation mechanism in place, then limit the certificate trust.

Do not make all of your components trust a single internal CA that issued all the certificates.

Also, establish the trust at the individual interfaces level (e.g., server A communicates with server B, so server A needs to trust the cert from server B but not its CA).

3. Automate Cert Renewal/Refresh

Automation is the only viable and reliable way to implement truly secure certificate management processes.

Automation allows for frequent certificate/key rotation, easy enforcement of all the certificate policies, full visibility, and control.

An automated process ideally should provide all the CA functions plus certificate distribution and installation.

The automated installation routine should allow for distributing a particular cert to all the instances (containers, VMs, etc.) constituting a given service.

4. Do not Use Self-Signed Certs

Self-signed certs have no provenance. Anyone can create them. There is no CA to consult the validity of the cert (e.g., via OCSP). It is hard to enforce various policies for self-signed certs, such as the signature type, the key length, etc.

Self-signed certs provide no audit trail and no journaling similar to the ones mandated by Google’s certificate transparency standard.

5. Create/Maintain Certificate Inventory

There are many security scanners that scan ports and pre-defined endpoints. However, it is also important to look inside Java key stores, PEM files, and all the other artefacts containing crypto material that are bundled inside applications and may not be discoverable by a scanning process.

For example, there is no way to identify SSL client certificates just by running an endpoint scanner.

Having a complete inventory of all active certificates/keys, including their location on disk, is extremely important.

This allows for efficiently dealing with compromised certs, this is also the first step towards automating the certificate/key management process.

 

READ ALSO!!!

Important Guide on Certificate Validity Period Best Practice

Below are some important guidelines on certificate validity period best practices:

1. Scan Certs Frequently

Many organizations have heavy-weight application/security scanning processes that take a while to run.

The result of the scan is often a voluminous report that takes a while to go through and act upon. Thus the scan runs infrequently.

Certificate scanning can be quick. It can also be paired with the automated refresh process so that the certificates/keys close to their expiration are automatically refreshed.

2. Scan Non-HTTP Endpoints

Many databases and messaging products use TLS over TCP (as opposed to HTTP). This includes SQL Server, Oracle, ActiveMQ, etc.

It’s more difficult to check old TCP endpoints and some security scanners do not have good support for them.

Make sure that you have an inventory of all non-HTTP endpoints and their certificates; their scanning should be part of a regular scanning process.

3. Secure Private Keys

Keys must always be protected by a password. Applications should not store these passwords in plain text.

If you can, use a secret manager, such as HashiCorp Vault, or an alternative to storing your keys. Unfortunately, implementing these products usually takes some effort for application developers.

For Java/JVM-based applications, Keystore files serve as the de-facto “secrets repository” (for better or worse). Please follow our Keystore best practices for the specific recommendations on Keystore management.

4. Secure Root Keys

Root certificates/keys used for issuing other certificates must be guarded with special care; access to these files must be strictly controlled.

READ ALSO!!!

5. Minimize Trust

Certificates determine trust relationships between components, at least at the transport level. Foremost, you need to understand the data flow in our system and regulate trust accordingly.

It is much easier to deploy an internal CA cert to all services so that all trust all but this is certainly a less secure approach.

This approach is advisable only if there is a solid internal certificate validation/revocation process in place.

When certificate deployment is fully automated, point-to-point trust at a service level is easily implemented.

With the above guidelines and steps, you are sure of your certificate validity period best practice. However, if you find this article useful, share it. Also, you can always visit this web page with great information like this.

StudentsandScholarship Team.