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

Notice

THIS FIELD NOTICE IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTY OF MERCHANTABILITY. YOUR USE OF THE INFORMATION ON THE FIELD NOTICE OR MATERIALS LINKED FROM THE FIELD NOTICE IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS FIELD NOTICE AT ANY TIME.

Revision History

Products Affected

Defect Information

Problem Description

Self-signed X.509 PKI certificates (SSC) that were generated on devices that run affected Cisco IOS^® or Cisco IOS XE software releases expire on 2020-01-01 00:00:00 UTC. New self-signed certificates cannot be created on affected devices after 2020-01-01 00:00:00 UTC. 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.

Note: To be impacted by this issue, 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.

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 expiration date of the self-signed certificate to 2020-01-01 00:00:00 UTC. After this date, the certificate expires and is invalid.

Note: A Cisco IOS or Cisco IOS XE device does not have to run an affected software version in order for its SSC to expire. All PKI certificates eventually expire. An SSC might have been generated and installed when the device previously ran an impacted software version. It is a recommended best-practice to monitor certificate expiration dates on all devices, even those that run software with the fix applied.

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.

WAN Features:

• WAAS - New routers cannot be added to a WAAS Central Manager after the self-signed certificate expires. Existing routers are not affected.

Problem Symptom

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 will be affected. 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 might 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.

Workaround/Solution

The solution is to deploy one of the workarounds described below or 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 ALSO regenerate the self-signed certificate and export it to any devices that might require the new certificate in their trust-store.

The three workarounds that are described below are just as effective as a software upgrade and are the preferred solution if an immediate software upgrade is not feasible.

Workaround 1

Install a certificate from a CA.

In 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 local Cisco IOS CA 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 PKCS12 certificate bundle and import the bundle to Cisco IOS.

1. Generate a PKCS12 certificate bundle:

   Linux, UNIX, or macOS 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
<OUTPUT OMITTED FOR BREVITY>
tT6r4SuibYKu6HV45ffjSzOimcJI+D9LKhLWR6pK/k5ge8v7aK9/rsVbjavbdy7b
CSqGSIb3DQEJFTEWBBS96DY/gRfN1dSx46P1EqjPvSYiETAxMCEwCQYFKw4DAhoF
AAQU+EX0kNvuNz6XmFxXER8wlqKTGvgECA+D+Z81uwafAgIIAA==

2. Import the certificate to a Cisco IOS or IOS XE Router:

   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.
R1(config)#

3. 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
   

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. Find the crypto PKI trustpoint configuration.

3. In the crypto PKI trustpoint configuration, look for the trustpoint enrollment configuration. If the trustpoint enrollment is configured for "selfsigned," then look for the selfsigned certificate configuration.

   Output 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. 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 <self-signed-trustpoint-name>
  ! or
  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:

  telephony-service
   secure-signaling trustpoint <self-signed-trustpoint-name>
   tftp-server-credentials trustpoint <self-signed-trustpoint-name>

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

  credentials
   trustpoint <self-signed-trustpoint-name>
  

• 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 <self-signed-trustpoint-name>
  !
  dspfarm profile 2 mtp security
  trustpoint <self-signed-trustpoint-name>
  !
  dspfarm profile 3 transcode security
   trustpoint <self-signed-trustpoint-name>
  !
  sccp ccm 127.0.0.1 identifier 1 priority 1 version 7.0 trustpoint <self-signed-trustpoint-name>
  !

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

  stcapp security trustpoint <self-signed-trustpoint-name>
  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 on Cisco IOS, this text will be present in the configuration file:

  webvpn gateway <gw name>
   ssl trustpoint TP-self-signed-XXXXXXXX

• For SSLVPN on Cisco IOS XE, this text will be present in the configuration file:

  crypto ssl policy <policy-name>
   pki trustpoint <trustpoint-name> sign

• For IKEv2, the self-signed certificate is used if this configuration is present:

  crypto ikev2 profile <prof name>
   authentication local rsa-sig
   pki trustpoint TP-self-signed-xxxxxx

• For ISAKMP (IKEv1), the self-signed certificate is used if this configuration is present:

  crypto isakmp profile <prof name>
   ca trust-point TP-self-signed-xxxxxx
  

  Note: Any ISAKMP policy that does not specify an authentication method (see the example below) will also use the SSC.

	crypto isakmp policy <number>
	 encryption aes
	 hash sha
	 group 5
	 lifetime 84400
	!

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

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

Note: You may notice the self-signed certificate truststore name shown in the output of the show ip ssh CLI command. This is NOT an indication that you are exposed to the issue described in this Field Notice. If you only log into a device with a username / password or by use of an RSA key pair, you are NOT affected by this Field Notice.

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

  restconf
   ip http secure-trustpoint TP-self-signed-XXXXXXXXX
  ! OR
   ip http client secure-trustpoint TP-self-signed-XXXXXXXX

• For WAAS, there is no specific configuration file text to identify. The trustpoint configuration and SSC configuration that are described in steps 1 - 3 above are sufficient. The device is affected if it runs Cisco IOS XE and is configured with an SSC (as described in steps 1 - 3 above) that expires on 2020-01-01 00:00:00 UTC.

Note: Existing WAAS deployments are not affected by an expired SSC. However, new WAAS Appnav-XE (Cisco IOS XE) devices cannot be registered after the SSC expires. The SSC validity is only checked when WAAS registers a new Appnav-XE device to the WAAS Central Manager (CM).

Additional Information

For additional technical details, refer to IOS Self-Signed Certificate Expiration on Jan. 1, 2020.

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

• Open a service request on Cisco.com
• By email
• By telephone

Receive Email Notification For New Field Notices

My Notifications—Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.