By default, if you install a ca server on january 1, 2022, when does the ca certificate expire?

Introduction

Note: This document contains the contents of FN40789, along with additional context, examples, updates, and Q&As.

At 00:00 on 1 Jan 2020 UTC, all Self-Signed Certificates (SSC) that were generated on IOS/IOS-XE systems will expire, unless the system was running a fixed version of IOS/IOS-XE when the SSC was generated.  After that time, unfixed IOS systems will be unable to generate new SSCs.  Any service that relies on these self-signed certificates to establish or terminate a secure connection might not work after the certificate expires.

This issue affects only self-signed certificates that were generated by the Cisco IOS or Cisco IOS XE device and applied to a service on the device. Certificates that were generated by a Certificate Authority (CA), which includes those certificates generated by the Cisco IOS CA feature, are not impacted by this issue.

Affected Systems

All IOS/IOS-XE systems using a Self-Signed Certficate, that do not have the CSCvi48253

fix, or that did not have the CSCvi48253 fix when the SSC was generated.  This includes:

• all IOS 12.x
• all IOS 15.x prior to 15.6(3)M7, 15.7(3)M5, 15.8(3)M3, 15.9(3)M
• all IOS-XE prior to 16.9.1

Background

Certain features in Cisco IOS and Cisco IOS XE software rely on digitally signed X.509 certificates for cryptographic identity validation. These certificates can be generated by an external third-party CA or they can be generated on the Cisco IOS or Cisco IOS XE device itself as a self-signed certificate. Affected releases of Cisco IOS and Cisco IOS XE software will always set the self-signed certificate's expiration date to 2020-01-01 00:00:00 UTC. After this date, the certificate expires and is invalid.

Services that might rely on a self-signed certificate include:

General Features:

• HTTP Server over TLS (HTTPS) - HTTPS will produce an error in the browser which indicates that the certificate is expired.
• SSH Server - Users who use X.509 certificates to authenticate the SSH session might fail to authenticate. (This use of X.509 certificates is rare. Username/password authentication and public/private key authentication are not affected.)
• RESTCONF - RESTCONF connections might fail.

Collaboration Features:

• Session Initiation Protocol (SIP) over TLS
• Cisco Unified Communications Manager Express (CME) with encrypted signaling enabled
• Cisco Unified Survivable Remote Site Telephony (SRST) with encrypted signaling enabled
• Cisco IOS dspfarm resources (Conference, Media Termination Point, or Transcoding) with encrypted signaling enabled
• Skinny Client Control Protocol (SCCP) Telephony Control Application (STCAPP) ports configured with encrypted signaling
• Media Gateway Control Protocol (MGCP) and H.323 call signaling over IP security (IPSec) without a pre-shared key
• Cisco Unified Communications Gateway Services API in Secure Mode (using HTTPS)

Wireless Features:

• LWAPP/CAPWAP connections between older Cisco IOS access points (manufactured in 2005 or earlier) and Wireless LAN Controllers; see Cisco Field Notice FN63942 for more details.

An attempt to generate a self-signed certificate on an affected Cisco IOS or Cisco IOS XE software release after 2020-01-01 00:00:00 UTC results in this error:

  ../cert-c/source/certobj.c(535) : E_VALIDITY : validity period start later than end

Any services that rely on the self-signed certificate may not function. For example:

• SIP over TLS calls will not complete.
• Devices registered to Cisco Unified CME with encrypted signaling enabled will no longer function.
• Cisco Unified SRST with encrypted signaling enabled will not allow devices to register.
• Cisco IOS dspfarm resources (Conference, Media Termination Point, or Transcoding) with encrypted signaling enabled will no longer register.
• STCAPP ports configured with encrypted signaling will no longer register.
• Calls through a gateway using MGCP or H.323 call signaling over IPSec without a pre-shared key will fail.
• API calls that use the Cisco Unified Communications Gateway Services API in Secure Mode (using HTTPS) will fail.
• RESTCONF may fail.
• HTTPS sessions to manage the device will display a browser warning, which indicates that the certificate has expired.
• AnyConnect SSL VPN sessions will fail to establish or report an invalid certificate.
• IPSec connections will fail to establish.

How to Identify Affected Products

Note: To be impacted by this field notice, a device must have a self-signed certificate defined AND the self-signed certificate must be applied to one or more features as outlined below. Presence of a self-signed certificate alone will not impact the operation of the device when the certificate expires and does not require immediate action. To be impacted, a device must meet the criteria in BOTH Step 3 and Step 4 below.

In order to determine if you use a self-signed certificate, complete these steps:

1. Enter the show running-config | begin crypto command on your device.

2. Look for the crypto PKI trustpoint configuration.

3. In the crypto PKI trustpoint configuration, look for the trustpoint enrollment configuration. The trustpoint enrollment must be configured for “selfsigned” to be impacted. Additionally, the self-signed certificate must also appear in the configuration. Note that the trustpoint name might not contain the words “self-signed” as shown in this example.

   crypto pki trustpoint TP-self-signed-XXXXXXXX   enrollment selfsigned   subject-name cn=IOS-Self-Signed-Certificate-662415686   revocation-check none   rsakeypair TP-self-signed-662415686 ! ! crypto pki certificate chain TP-self-signed-XXXXXXXX certificate self-signed 01   3082032E 31840216 A0030201 02024101 300D0609 2A864886 F70D0101 05050030   30312E30 2C060355 04031325 494A531D 53656C66 2D536967 6E65642D 43657274   ...   ECA15D69 11970A66 252D34DC 760294A6 D1EA2329 F76EB905 6A5153C9 24F2958F   D19BFB22 9F89EE23 02D22D9D 2186B1A1 5AD4

   If the trustpoint enrollment is not configured for "selfsigned" - The device is NOT impacted by this field notice. No action is required.

   If the trustpoint enrollment is configured for "selfsigned" and if the self-signed certificate appears in the configuration - The device might be impacted by this field notice. Continue to Step 4.

4. If you determined in Step 3 that the trustpoint enrollment is configured for "selfsigned" and that the self-signed certificate appears in the configuration, then check to see if the self-signed certificate is applied to a feature on the device.

   Various features that might be tied to the SSC are shown in these sample configurations:

   
   

• For HTTPS Server, this text must be present:ip http secure-server

Additionally, a trustpoint may also be defined as shown below. If the command below is not present, the default behavior is to use the self-signed certificate.

ip http secure-trustpoint TP-self-signed-XXXXXXXX

If a trustpoint is defined and it points to a certificate other than the self-signed certificate, you are not impacted.

For HTTPS Server, the impact of the expired certificate is minor because self-signed certificates are already untrusted by web browsers and generate a warning even when they are not expired. The presence of an expired certificate may change the warning you receive in the browser.

• For SIP over TLS, this text will be present in the configuration file:

  voice service voip sip   session transport tcp tls ! sip-ua crypto signaling default trustpoint ! or crypto signaling remote-addr a.b.c.d /nn trustpoint !

• For Cisco Unified CME with encrypted signaling enabled, this text will be present in the configuration file:

  telephony-service secure-signaling trustpoint tftp-server-credentials trustpoint

• For Cisco Unified SRST with encrypted signaling enabled, this text will be present in the configuration file:

  credentials trustpoint

• For Cisco IOS dspfarm resources (Conference, Media Termination Point, or Transcoding) with encrypted signaling enabled, this text will be present in the configuration file:

  dspfarm profile 1 conference security trustpoint ! dspfarm profile 2 mtp security trustpoint ! dspfarm profile 3 transcode security trustpoint ! sccp ccm 127.0.0.1 identifier 1 priority 1 version 7.0 trustpoint !

• For STCAPP ports configured with encrypted signaling, this text will be present in the configuration file:

  stcapp security trustpoint stcapp security mode encrypted

• For Cisco Unified Communications Gateway Services API in Secure Mode, this text will be present in the configuration file:

  uc secure-wsapi ip http secure-server ip http secure-trustpoint TP-self-signed-XXXXXXXX

• For SSLVPN, this text will be present in the configuration file:

  webvpn gateway ssl trustpoint TP-self-signed-XXXXXXXX

  OR

  crypto ssl policy
  pki trustpoint sign

• For ISAKMP and IKEv2, the self-signed certificate might be used if any of the configurations is present (further analysis of the configuration is required in order to determine if the feature uses the self-signed certificate versus a different certificate):

  crypto isakmp policy authentication pre-share | rsa-encr < NOT either of these ! crypto ikev2 profile authentication local rsa-sig pki trustpoint TP-self-signed-xxxxxx ! crypto isakmp profile ca trust-point TP-self-signed-xxxxxx

• For SSH Server, Please NOTE:  It is extreemly unlikely that you are leveraging certificates to authenticate the SSH sessions.  However, you can verify this by checking your configuration.  You must have all three lines below in order to be impacted. 

  Note 2: IF you leverage username and password combination to SSH into your device then you are NOT impacted.

  ip ssh server certificate profile ! Certificate used by server server   trustpoint sign TP-self-signed-xxxxxx

• For RESTCONF, this text will be present in the configuration file:

  restconf
  ! And one of the following ip http secure-trustpoint TP-self-signed-XXXXXXXXX ! OR ip http client secure-trustpoint TP-self-signed-XXXXXXXX

Workaround / Solution(s)

The solution is to upgrade the Cisco IOS or Cisco IOS XE software to a release that includes the fix:

• Cisco IOS XE Software Release 16.9.1 and later
• Cisco IOS Software Release 15.6(3)M7 and later; 15.7(3)M5 and later; or 15.8(3)M3 and later

After you upgrade the software, you must regenerate the self-signed certificate and export it to any devices that might require the certificate in their trust-store.

Three workarounds are available if an immediate software upgrade is not feasible.

Workaround 1 - Obtain a valid certificate from a 3rd part Certificate Authority (CA)

Install a certificate from a certificate authority.  Common CAs include:  Comodo, Let's Encrypt, RapidSSL, Thawte, Sectigo, GeoTrust, Symantec, and many others.

With this workaround, a certificate request is generated and displayed by Cisco IOS. The administrator then copies the request and submits it to a third-party CA and retrieves the result.

Note: Use of a CA to sign certificates is considered to be a security best-practice. This procedure is provided as a workaround in this field notice; however, it is preferable to continue to use the third-party CA-signed certificate after you apply this workaround, rather than to use a self-signed certificate.

In order to install a certificate from a third-party CA, complete these steps:

1. Create a Certificate Signing Request (CSR).

   Router# conf t
   Enter configuration commands, one per line. End with CNTL/Z.
   Router(config)# crypto pki trustpoint TEST
   Router(ca-trustpoint)# enrollment term pem
   Router(ca-trustpoint)# subject-name CN=TEST
   Router(ca-trustpoint)# revocation-check none
   Router(ca-trustpoint)# rsakeypair TEST
   Router(ca-trustpoint)# exit
   Router(config)# crypto pki enroll TEST
   % Start certificate enrollment ..
   % The subject name in the certificate will include: CN=TEST
   % The subject name in the certificate will include: Router.cisco.com
   % The serial number in the certificate will be: FTX1234ABCD
   % Include an IP address in the subject name? [no]: no
   Display Certificate Request to terminal? [yes/no]: yes
   Certificate Request follows:
   -----BEGIN CERTIFICATE REQUEST-----
   A Base64 Certificate is displayed here. Copy it, along with the ---BEGIN and ---END lines.
   -----END CERTIFICATE REQUEST-----
   ---End - This line not part of the certificate request---

2. Submit the CSR to the third-party CA.

   Note: The procedure to submit the CSR to a third-party CA and retrieve the resulting certificate varies based on the CA that is being used. Consult the documentation for your CA for instructions on how to perform this step.

3. Download the new identity certificate for the router along with the CA certificate.

4. Install the CA certificate on the device.

   Router# conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# crypto pki auth TEST Enter the base 64 encoded CA certificate. End with a blank line or the word "quit" on a line by itself -----BEGIN CERTIFICATE----- REMOVED -----END CERTIFICATE----- Certificate has the following attributes: Fingerprint MD5: 79D15A9F C7EB4882 83AC50AC 7B0FC625 Fingerprint SHA1: 0A80CC2C 9C779D20 9071E790 B82421DE B47E9006 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. % Certificate successfully imported

5. Install the identity certificate on the device.

   Router(config)# crypto pki import TEST certificate Enter the base 64 encoded certificate. End with a blank line or the word "quit" on a line by itself -----BEGIN CERTIFICATE----- REMOVED -----END CERTIFICATE----- % Router Certificate successfully imported

Workaround 2 - Use the IOS CA Server to generate a new certificate

Use the local Cisco IOS Certificate Authority server to generate and sign a new certificate.

Note: The local CA server feature is not available on all products.

Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip http server
Router(config)# crypto pki server IOS-CA
Router(cs-server)# grant auto
Router(cs-server)# database level complete
Router(cs-server)# no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password:
Re-enter password:
% Generating 1024 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 1 seconds)
% Certificate Server enabled.Router# show crypto pki server IOS-CA Certificates
Serial Issued date Expire date Subject Name
1 21:31:40 EST Jan 1 2020 21:31:40 EST Dec 31 2022 cn=IOS-CA

Router# conf t

Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# crypto pki trustpoint TEST
Router(ca-trustpoint)# enrollment url http://:80 # Replace with the IP address of an interface on the router
Router(ca-trustpoint)# subject-name CN=TEST
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# rsakeypair TEST
Router(ca-trustpoint)# exit
Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# crypto pki auth TEST
Certificate has the following attributes:
Fingerprint MD5: C281D9A0 337659CB D1B03AA6 11BD6E40
Fingerprint SHA1: 1779C425 3DCEE86D 2B11C880 D92361D6 8E2B71FF
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Router(config)# crypto pki enroll TEST
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will include: CN=TEST
% The subject name in the certificate will include: Router.cisco.com
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: FTX1234ABCD
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose TEST' command will show the fingerprint.

Workaround 3 - use OpenSSL to generate a new self-signed certificate

Use OpenSSL to generate a PKCS12 certificate bundle and import the bundle to Cisco IOS.

LINUX, UNIX or MAC (OSX) Example

User@linux-box$ openssl req -newkey rsa:2048 -nodes -keyout tmp.key -x509 -days 4000 -out tmp.cer -subj
"/CN=SelfSignedCert" &> /dev/null && openssl pkcs12 -export -in tmp.cer -inkey tmp.key -out tmp.bin
-passout pass:Cisco123 && openssl pkcs12 -export -out certificate.pfx -password pass:Cisco123 -inkey
tmp.key -in tmp.cer && rm tmp.bin tmp.key tmp.cer && openssl base64 -in certificate.pfx
MIII8QIBAzCCCLcGCSqGSIb3DQEHAaCCCKgEggikMIIIoDCCA1cGCSqGSIb3DQEH
BqCCA0gwggNEAgEAMIIDPQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQYwDgQIGnxm
t5r28FECAggAgIIDEKyw10smucdQGt1c0DdfYXwUo8BwaBnzQvN0ClawXNQln2bT
vrhus6LfRvVxBNPeQz2ADgLikGxatwV5EDgooM+IEucKDURGLEotaRrVU5Wk3EGM
mjC6Ko9OaM30vhAGEEXrk26cq+OWsEuF3qudggRYv2gIBcrJ2iUQNFsBIrvlGHRo
FphOTqhVaAPxZS7hOB30cK1tMKHOIa8EwygyBvQPfjjBT79QFgeexIJFmUtqYX/P

tT6r4SuibYKu6HV45ffjSzOimcJI+D9LKhLWR6pK/k5ge8v7aK9/rsVbjavbdy7b
CSqGSIb3DQEJFTEWBBS96DY/gRfN1dSx46P1EqjPvSYiETAxMCEwCQYFKw4DAhoF
AAQU+EX0kNvuNz6XmFxXER8wlqKTGvgECA+D+Z81uwafAgIIAA==

Cisco IOS or IOS XE Router Example

Router# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# crypto pki trustpoint TEST
Router(ca-trustpoint)# enrollment terminal
Router(ca-trustpoint)# revocation-check none
Router(ca-trustpoint)# exit
R1(config)#crypto pki import TEST pkcs12 terminal password Cisco123
Enter the base 64 encoded pkcs12.
End with a blank line or the word "quit" on a line by itself:
MIII8QIBAzCCCLcGCSqGSIb3DQEHAaCCCKgEggikMIIIoDCCA1cGCSqGSIb3DQEH
BqCCA0gwggNEAgEAMIIDPQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQYwDgQItyCo
Vh05+0QCAggAgIIDENUWY+UeuY5sIRZuoBi2nEhdIPd1th/auBYtX79aXGiz/iEW

IY1l273y9bC3qPVJ0UGoQW8SGfarqEjaqxdAet66E5V6u9Yvd4oMsIYGsa70m+FN
CsUVj+ll5hzGjK78L0ycXWpH4gDOGYBVf+D7mgWqaqZvxYUoEkOrTMmW5zElMCMG
CSqGSIb3DQEJFTEWBBSgiBJIYpJLzo/GYN0sesZh3wGmPTAxMCEwCQYFKw4DAhoF
AAQUdeUrLIC2uo/mbyE86he5+qEjmPYECKu76GWaeKb7AgIIAA==
quit
CRYPTO_PKI: Imported PKCS12 file successfully.

R1(config)#

Verify that the new certificate is installed:

R1#show crypto pki certificates TEST Load for five secs: 5%/1%; one minute: 2%; five minutes: 3% Time source is SNTP, 15:04:37.593 UTC Mon Dec 16 2019 CA Certificate Status: Available Certificate Serial Number (hex): 00A16966E46A435A99 Certificate Usage: General Purpose Issuer: cn=SelfSignedCert Subject: cn=SelfSignedCert Validity Date: start date: 14:54:46 UTC Dec 16 2019 end date: 14:54:46 UTC Nov 28 2030

More Information

See FN70489  Field Notice: FN - 70489 - PKI Self-Signed Certificate Expiration in Cisco IOS and Cisco IOS XE Software

See CSCvi48253

Self-signed certificates expire on 00:00 1 Jan 2020 UTC, can't be created after that time.

Q&A

Q: What is the issue?

Self-signed X.509 PKI certificates generated on products running affected Cisco IOS or Cisco IOS-XE versions expire on 01/01/2020 00:00:00 UTC. New self-signed certificates cannot be created on affected devices after 01/01/2020 00:00:00 UTC. Any service relying on these self-signed certificates may no longer work after the certificate expires.

Q: What is the impact to a customer’s network if a product’s self-signed certificate expires?

Any affected product’s functionality that relies on the self-signed certificates may no longer work after the certificate expires. Please see the Field Notice for additional detail.

Q: How do I know if I’m affected by this issue?

The Field Notice provides instructions to determine if you are using a self-signed certificate and whether your configuration is affected by this issue. Please see the “How To Identify Affected Products” section in the Field Notice.

Q: Is there a script that I can run to see if I am affected?

Yes. Using Cisco CLI Analyzer, run an System Diagnostic run. If the certificate is present and being used an alert will be shown. https://cway.cisco.com/cli/

Q. Has Cisco provided software fixes for this issue?

Yes. Cisco has released software fixes for this issue as well as workarounds in the event a software upgrade is not immediately feasible. Please see the Field Notice for complete detail.

Q: Does this issue affect any Cisco product using a certificate?

No. This issue affects only products using self-signed certificates generated by specific versions of Cisco IOS or Cisco IOS-XE with the certificate applied to a service on the product. Products using Certificates generated by a Certificate Authority (CA) are not impacted by this issue.

Q: Do Cisco products use only self-signed certificates?

No. Certificates can be generated by an external 3rd-party Certificate Authority or they can be generated on the Cisco IOS or Cisco IOS-XE device itself as a self-signed certificate. Specific customer requirements may lead to the choice of using self-signed certificates. Certificates generated by a Certificate Authority (CA) are not impacted by this issue.

Q. Why did this issue occur?

Unfortunately, despite the best efforts of technology vendors, software defects do still occur. When a bug is discovered in any Cisco technology, we are committed to transparency and to providing our customers the information they need to protect their network.

In this case, the issue is caused by a known software bug in which affected versions of Cisco IOS and Cisco IOS-XE will always set the self-signed certificate’s expiration date to 01/01/2020 00:00:00 UTC. After this date, the certificate expires and is invalid, which could impact product functionality.

Q: Why was an expiration date of January 1, 2020 00:00:00 UTC chosen?

Certificates commonly have an expiration date. In the case of this software bug, the January 1, 2020 date was used during Cisco IOS and Cisco IOS-XE software development over 10 years ago and is a human error.

Q: What products are affected by this issue?

Any Cisco product running Cisco IOS releases prior to 15.6(03)M07, 15.7(03)M05, 15.8(03)M03, and 15.9(03)M and any Cisco product running Cisco IOS-XE releases prior to 16.9.1

Q: What do customers need to do?

We ask our customers to review the field notice to assess whether they are impacted by this issue and, if so, to follow the Workaround/Solution instructions to mitigate this issue.

Q: Is this issue a security vulnerability?

No. This is not a security vulnerability, and there is no risk to the integrity of the product.

Q: Is SSH affected?

No. SSH does use RSA keypairs but doesn't utilize certificates except in a rare configuration. For IOS to utilize certificates the following configuration must be present.

ip ssh server certificate profile server trustpoint sign TP-self-signed-xxxxxx

Q: What Fixed Versions are available for the Classic Catalyst 2K, 3K, 4K, 6K platforms?

For Polaris based platforms(3650/3850/Catalyst 9K series), fix is available 16.9.1 onwards
For CDB platform, fix is available 15.2(7)E1a  onwards

For the other Classic Switching Platforms: 

Commits are in progress but we do not have posted CCO Release. Next CCO Release will have the fix.

In the interm please utilize one of the other available workarounds.

Q: Is WAAS affected?

WAAS will continue to operate properly and optimize traffic however, AppNav-XE & the Central Manager will go offline to the device that has an expired self-signed certificate. This means one cannot monitor AppNav-Cluster or change any policies for WAAS. In summary, WAAS will continue to work properly, but management and monitoring will be suspended until the certificate issue is resolved.   To resolve the issue, a new certificate will need to be generated on IOS and then imported into the Central Manager.

How long is a CA certificate valid?

By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. After one year, the certificate expires and is not trusted for use.

How can I tell when a server certificate expires?

Chrome has made it simple for any site visitor to get certificate information with just a few clicks:.

Click the padlock icon in the address bar for the website..

Click on Certificate (Valid) in the pop-up..

Check the Valid from dates to validate the SSL certificate is current..

How long does an SSL certificate last?

SSL Certificate comes up with the validity of 1 year or 2 years and the Certificate Authority sends the renewal reminder as per their schedule. Now, if you forget to renew your certificate, the browser shows the Expired SSL Certificate warning.

How do I know if my CA certificate is installed?

You can perform this with the following command: sudo update-ca-certificates . You will notice that the command reports it has installed certificates if required (up-to-date installations may already have the root certificate).