PDF(67.8 KB) View with Adobe Reader on a variety of devices
ePub(90.0 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(84.2 KB) View on Kindle device or Kindle app on multiple devices
Updated:December 25, 2019
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
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
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:
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.
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)
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:
Enter the show running-config | begin crypto command on your device.
Look for the crypto PKI trustpoint configuration.
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.
If the trustpoint enrollment isnotconfigured for "selfsigned" - The device is NOT impacted by this field notice. No action is required.
If the trustpoint enrollmentisconfigured 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.
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
session transport tcp tls
crypto signaling default trustpoint <self-signed-trustpoint-name>
crypto signaling remote-addr a.b.c.d /nn trustpoint <self-signed-trustpoint-name>
For Cisco Unified CME with encrypted signaling enabled, this text will be present in the configuration file:
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 <number>
authentication pre-share | rsa-encr < NOT either of these
crypto ikev2 profile <prof name>
authentication local rsa-sig
pki trustpoint TP-self-signed-xxxxxx
crypto isakmp profile <prof name>
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
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
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:
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---
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.
Download the new identity certificate for the router along with the CA certificate.
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
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
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
% 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: <password>
Re-enter password: <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://<local interface ip>:80 # Replace <local interface ip> 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: <passsword> Re-enter password: <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.
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 <OUTPUT OMITTED FOR BREVITY> IY1l273y9bC3qPVJ0UGoQW8SGfarqEjaqxdAet66E5V6u9Yvd4oMsIYGsa70m+FN CsUVj+ll5hzGjK78L0ycXWpH4gDOGYBVf+D7mgWqaqZvxYUoEkOrTMmW5zElMCMG CSqGSIb3DQEJFTEWBBSgiBJIYpJLzo/GYN0sesZh3wGmPTAxMCEwCQYFKw4DAhoF AAQUdeUrLIC2uo/mbyE86he5+qEjmPYECKu76GWaeKb7AgIIAA== quit
CRYPTO_PKI: Imported PKCS12 file successfully.
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
Certificate Serial Number (hex): 00A16966E46A435A99
Certificate Usage: General Purpose
start date: 14:54:46 UTC Dec 16 2019
end date: 14:54:46 UTC Nov 28 2030
See FN70489 Field Notice: FN - 70489 - PKI Self-Signed Certificate Expiration in Cisco IOS and Cisco IOS XE Software
See CSCvi48253Self-signed certificates expire on 00:00 1 Jan 2020 UTC, can't be created after that time.
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
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.