Self-Signed Cert Expiration Impact

Cisco published a Field Notice this week (here’s the link to the original document, CCO login required) that details how devices won’t form IPSEC connections because of the self-signed certificates expiring on January 1, 2020. It’s an issue in IOS and IOS-XE software, not for any other product lines.

We’ve been getting a lot more questions about this than usual, but the impact in our customer base has been minor, so here’s a quick recap of what’s at risk.

With all of these examples, if you’ve replaced the cert with a “real” (meaning issued by a Trusted CA) certificate, the defect doesn’t apply.


Unless you’re running X.509 based authentication (using certificates), you’re not at risk. Username and password SSH authentication is and will continue to work when you try to access the box for management access.


If you are running ‘ip http secure-server’ with a self-signed certificate, your web browser will show that your certificate is expired and untrusted. However, odds are that it says that anyways, since your browser doesn’t trust self-signed certs. If you are using RESTCONF to manage your devices and you’re doing strict certificate checking, that’ll break.

Collaboration Features

If you’re running SECURE voice (SRTP) this is an issue. This affects CME/SRST, dspfarm, SCCP and MGCP services, as well as API Gateway in HTTPS mode. This only will affect traffic going to an IOS or IOS XE gateway that’s encrypted.

IPSEC Tunnels

If you’re terminating tunnels on an IOS or IOS XE router and you are running “authentication local rsa-sig” in your ISAKMP profile with a self-signed certificate, the tunnel will break on 1/1/2020. If you have auth pre-share or auth rsa-encr in your config, you’re fine.


There’s a bug with old WAPs made before 2005 where the manufacturer certificate has an expiration date. Make sure you’re running a newer version of the code train you’re on and you should be good. Check the WAP compatibility matrix prior to upgrading. Here’s the link to that particular notice.

If you’re vulnerable, the simplest way to work around this issue (besides a software upgrade) is to generate a new certificate with OpenSSL, then import the certificate to the device. It’s documented in the Field Notice as Workaround 3.

bash# 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

Then, import it to the affected box and ensure the trustpoint is changed to the new entry (in this case, one named TEST):

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
Router(config)#crypto pki import TEST pkcs12 terminal password Cisco123

If you have any questions, please let me know!

Happy Holidays!

Share This