SSL Certificate Validity – Duration (Nessus 121009): How to Fix Overlong Certificate Lifetimes

SSL Certificate Validity – Duration (Nessus plugin 121009) means a TLS service presents a certificate whose lifetime, from notBefore to notAfter, is longer than the plugin allows: 825 days for certificates issued after March 1, 2018. Fix it by reissuing the certificate with a shorter lifetime and lowering the template or CA setting that produced it.

What the scanner is actually detecting

The plugin reads the validity dates of the certificate a TLS service presents and compares the total lifetime with the limits from CA/Browser Forum Ballot 193. Which limit applies depends on the certificate’s notBefore date:

• Issued on or before July 1, 2016: more than 60 months is flagged.
• Issued between July 1, 2016 and March 1, 2018: more than 39 months is flagged.
• Issued after March 1, 2018: more than 825 days is flagged.

Two details matter when you triage it. First, the plugin checks the lifetime no matter who issued the certificate, so self-signed and internal CA certificates are in scope. In practice they are almost the only certificates that still trigger it, because publicly trusted certificates issued since March 2018 could not exceed 825 days anyway. Second, the plugin does not follow the newer public limits. The CA/Browser Forum Baseline Requirements (section 6.3.2) now cap publicly trusted server certificates much lower:

So a 700-day internal certificate passes this plugin, even though no public CA could issue it today.

Real-world risk

Tenable rates plugin 121009 as Medium (CVSS v3 base score 4.8). A long lifetime is not something an attacker can exploit by itself. The risks are indirect:

• Longer key exposure: if the private key leaks, the certificate stays valid until it expires, and only revocation shortens that window, provided clients actually check revocation.
• Cryptographic drift: Tenable’s stated concern is that long-lived certificates keep outdated cryptography in production, such as a signature algorithm or key size you would no longer accept.
• No working renewal process: a certificate that renews once every five or ten years tends to expire without warning, because nobody remembers how it was issued.
• Client rejection: Apple’s requirements for iOS 13 and macOS 10.15 say TLS server certificates issued after July 1, 2019 must have a validity period of 825 days or fewer, and connections to servers that violate them fail. The page makes no exception for private CAs.

How to confirm it on the host

Read the dates the service actually serves. Use the hostname with -servername so you get the same certificate as real clients:

openssl s_client -connect app01.corp.example:443 -servername app01.corp.example </dev/null 2>/dev/null 
  | openssl x509 -noout -subject -issuer -dates

To turn the dates into a day count on Linux (GNU date), run this against a PEM file:

nb=$(openssl x509 -in app01.crt -noout -startdate | cut -d= -f2)
na=$(openssl x509 -in app01.crt -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$na" +%s) - $(date -d "$nb" +%s) ) / 86400 )) days

On Windows, list long-lived certificates in the computer’s Personal store:

Get-ChildItem Cert:LocalMachineMy |
  Select-Object Subject, NotBefore, NotAfter,
    @{Name='Days';Expression={[int]($_.NotAfter - $_.NotBefore).TotalDays}} |
  Where-Object Days -gt 825

For an exported file, certutil -dump app01.cer shows NotBefore, NotAfter and, for AD CS certificates, the template extension that tells you which template issued it.

How to fix it

Pick a target first. Anything at or under 825 days clears the plugin and Apple’s rule, but a year or less is a more practical internal target, and shorter is better once renewal is automated. Do not set the exact maximum: the Baseline Requirements count a validity period from notBefore through notAfter inclusive, so a certificate built to the limit can land one day over it.

Certificates from a public CA

If the flagged certificate chains to a public CA, it was issued before March 2018 under older rules and has almost certainly expired while still being served. Renew it through your CA or ACME client; the new certificate will be issued within the current limit automatically.

Self-signed certificates (Linux services and appliances)

Replacing a self-signed certificate with one from your internal CA is the better fix. Where self-signed is the only option, regenerate it with an explicit lifetime:

openssl req -x509 -newkey rsa:2048 -nodes -days 365 
  -keyout app01.key -out app01.crt 
  -subj "/CN=app01.corp.example" 
  -addext "subjectAltName=DNS:app01.corp.example"

For appliances that generate their own certificate, use the vendor’s regenerate or import function. If it cannot set a lifetime, import a CA-issued certificate instead.

Self-signed certificates on Windows

New-SelfSignedCertificate defaults to one year. If a script set a long -NotAfter, recreate the certificate with a short one and rebind the service:

New-SelfSignedCertificate -DnsName app01.corp.example `
  -CertStoreLocation Cert:LocalMachineMy `
  -NotAfter (Get-Date).AddDays(365)

AD CS enterprise CA: template and CA validity period

Microsoft documents that a certificate from an enterprise CA is valid for the shortest of: the CA’s registry validity period, the template validity period, and the remaining lifetime of the CA’s own certificate. The registry default for an enterprise CA is two years, so an enterprise certificate over 825 days means both the registry value and the template allow more than 825 days. Lowering either one fixes new issuance.

Option 1, the template (targeted). The built-in Web Server template is a version 1 template, and only its permissions can be changed. To shorten server certificates:

1. Open the Certificate Templates console (certtmpl.msc), right-click Web Server and choose Duplicate Template. If the certificate came from an existing custom template, edit that one instead.
2. On the General tab, set Validity period (for example, 1 year) and keep Renewal period shorter than it.
3. On the Security tab, grant Enroll to the servers or groups that need it.
4. In the Certification Authority console (certsrv.msc), right-click Certificate Templates, choose New then Certificate Template to Issue, and select the new template.

Option 2, the CA registry (a cap on everything). Record the current values, then lower them on the issuing CA and restart the service:

certutil -getreg caValidityPeriod
certutil -getreg caValidityPeriodUnits

certutil -setreg caValidityPeriod Years
certutil -setreg caValidityPeriodUnits 1

net stop certsvc
net start certsvc

On a standalone CA no templates are processed, so this registry value is the only control.

Reissue. Neither change touches certificates that already exist. Request a new certificate on the affected server with the template’s Template name from the General tab, then bind it to the service (for IIS, Site, Bindings, https):

Get-Certificate -Template WebServer1Year -Url ldap: `
  -SubjectName "CN=app01.corp.example" -DnsName app01.corp.example `
  -CertStoreLocation Cert:LocalMachineMy

OpenSSL-based internal CAs

Set default_days in the CA section of the configuration, or pass -days when signing, which overrides it:

[ CA_default ]
default_days = 365

openssl ca -config openssl.cnf -days 365 -in app01.csr -out app01.crt

Other CA products have an equivalent maximum lifetime on the role or profile; lower it there before reissuing.

How to verify the fix and rescan

1. Rerun the openssl s_client check against every port and node that serves the name, and confirm the new dates and day count.
2. On AD CS, confirm the new certificate shows the new template and the expected lifetime.
3. Run a targeted rescan with the same Nessus policy and credentials that raised the finding, and confirm plugin 121009 no longer appears for that host and port.

What can break and how to roll back

• A CA-wide cap shortens everything. Lowering ValidityPeriodUnits on an issuing CA also shortens user, computer and domain controller certificates. Certificates on autoenrollment renew themselves; manually installed ones on appliances and Linux servers will expire sooner.
• Do not do this on a root CA to fix a leaf. On a root, the same registry values govern the subordinate CA certificates it signs.
• Clients that trusted the old self-signed certificate (Java truststores, pinned API clients, monitoring agents) must be given the new one.
• Rollback: keep the old certificate installed until the new one is confirmed, and rebind it if something fails. Restore the registry values you recorded with certutil -setreg and restart certsvc. Revoke the old certificate only after cutover.

Common false positive reasons

• Scanning by IP address. Without the hostname (SNI), the server may return an old default certificate rather than the one you replaced.
• A TLS-inspecting proxy or load balancer presents its own long-lived certificate.
• Another node or port still serves the old certificate, for example a second cluster member or a management port.
• Stale results. The scan predates the replacement, or the service was not restarted after the certificate was swapped.

FAQ

Is SSL Certificate Validity – Duration a serious vulnerability?

No. Tenable rates it Medium (CVSS v3 4.8). It is a hygiene issue that widens the impact of a key compromise, not a direct attack path.

Do the 398-day and 200-day limits apply to our internal CA?

No. The Baseline Requirements govern publicly trusted CAs, and Apple states that its 398-day limit does not affect certificates from user-added or administrator-added roots. Apple’s 825-day rule for iOS 13 and macOS 10.15 makes no such exception, and this plugin checks every certificate.

Why was my 500-day certificate not flagged?

For certificates issued after March 1, 2018, plugin 121009 only flags lifetimes over 825 days.

Does changing the template or CA setting fix existing certificates?

No. It only affects new issuance. You must reissue and rebind each flagged certificate.

Tracking this finding across many hosts

Long lifetimes come back whenever someone reissues from an old template, so a TLS certificate inventory with owners and lifetimes helps catch them early. Certificate transparency discovery covers public names only, so it will not show the internal certificates that usually trigger this plugin. If you work through this at scale, SITEY is a self-hosted vulnerability management platform that imports findings from 16 scanners, including Nessus results uploaded as .nessus exports, and supports per-finding retest for Nessus findings.

Sources

• Tenable: SSL Certificate Validity – Duration (plugin 121009)
• CA/Browser Forum: Baseline Requirements for TLS Server Certificates
• Microsoft Learn: Change expiration date of certificates issued by a CA
• Microsoft Learn: Certificate template concepts in Windows Server
• Apple: Requirements for trusted certificates in iOS 13 and macOS 10.15