0

I'm trying to get some assistance over on the Network Engineering Stack Exchange but they really want to blame the browser (see the comments there). I am looking for a fix that does not modify the browser settings (though I am open to modifying them to determine the issue) and which still allows for a self-signed certificate to be used. I use many self-signed certificates with Firefox on other servers and am well aware of how Firefox treats self-signed certificate errors, this is not the same thing, there is something else going on that the Cisco Router does not like about the TLS connection options proposed by Firefox.

Anyway... I have a Cisco ISR4331/K9 running IOS XE Version 16.09.04 which I have configured with a hostname, domain name, and generated 2048 bit RSA keys on, I have also verified the clock is set correctly.

After configuring ip http secure-server I am trying to access the router from a PC running Firefox 83.0

While HTTP access is working HTTPS gets stuck with an error "SSL_ERROR_NO_CYPHER_OVERLAP" in Firefox. However a sh ip http server secure status returns:

HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite:  3des-ede-cbc-sha aes-128-cbc-sha
        aes-256-cbc-sha dhe-aes-128-cbc-sha ecdhe-rsa-3des-ede-cbc-sha
        rsa-aes-cbc-sha2 rsa-aes-gcm-sha2 dhe-aes-cbc-sha2 dhe-aes-gcm-sha2
        ecdhe-rsa-aes-cbc-sha2 ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2
HTTP secure server TLS version:  TLSv1.2 TLSv1.1
HTTP secure server client authentication: Disabled
HTTP secure server PIV authentication: Disabled
HTTP secure server trustpoint: 
HTTP secure server peer validation trustpoint: 
HTTP secure server ECDHE curve: secp256r1
HTTP secure server active session modules: ALL

This would seem to be a perfectly acceptable list of cipher suites for Firefox.

Upon looking in Wireshak it appears the router is immediately returning a TLSv1.2 Fatal Handshake Error message to the browser right after the TLSv1.2 Hello message from the client.

I don't get any messages at all on the router using debug ip http all during this handshake.

Any idea what am I missing here?

Note that this is a lab router I'm using for replicating/debugging this issue so it is lacking most configuration. Router configuration:

routertest#sh run
Building configuration...


Current configuration : 1787 bytes
!
! Last configuration change at 18:22:01 UTC Fri Jan 29 2021
!
version 16.9
service timestamps debug datetime msec
service timestamps log datetime msec
platform qfp utilization monitor load 80
no platform punt-keepalive disable-kernel-core
!
hostname routertest
!
boot-start-marker
boot-end-marker
!
!
vrf definition Mgmt-intf
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
no aaa new-model
!
no ip domain lookup
ip domain name test.com
!
!
!
login on-success log
!
!
!
!
!
!
!
subscriber templating
! 
! 
! 
! 
!         
multilink bundle-name authenticated
!
!
!
crypto pki trustpoint TP-self-signed-886488406
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-886488406
 revocation-check none
 rsakeypair TP-self-signed-886488406
!
!
crypto pki certificate chain TP-self-signed-886488406
!
license udi pid ISR4331/K9 sn FDO19370HXL
license boot level securityk9
no license smart enable
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
!
!         
redundancy
 mode none
!
!
!
!
!
!
! 
!
!
!
!
!
!
!
!
!
!
! 
! 
!
!         
interface GigabitEthernet0/0/0
 no ip address
 shutdown
 negotiation auto
!
interface GigabitEthernet0/0/1
 ip address 10.30.0.1 255.255.255.0
 negotiation auto
!
interface GigabitEthernet0/0/2
 no ip address
 shutdown
 negotiation auto
!
interface Serial0/1/0
 no ip address
!
interface Serial0/1/1
 no ip address
!
interface GigabitEthernet0
 vrf forwarding Mgmt-intf
 no ip address
 shutdown
 negotiation auto
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip tftp source-interface GigabitEthernet0
!
!
!
!
!
!
control-plane
!
!
line con 0
 logging synchronous
 transport input none
 stopbits 1
line aux 0
 stopbits 1
line vty 0 4
 login
!
!
!
!
!
!
end
Ben Franske
  • 511
  • 2
  • 11
  • Firefox 83.0 on what operating system? – Michael Hampton Jan 30 '21 at 01:15
  • Windows 10 (20H2 I think) – Ben Franske Jan 30 '21 at 02:16
  • What happened when you tried a different browser? What happened when you tried a different operating system? – Michael Hampton Jan 30 '21 at 02:22
  • The systems are airgapped from the Internet so it's a bit of a pain to try, but they do have Edge (the old one, not Chrome based) which gave a slightly different error... "Can't connect securely to this page...This might be because the site uses outdated or unsafe TLS security settings." – Ben Franske Jan 30 '21 at 03:09
  • It looks like even IE 11 is complaining about "Outdated or unsafe TLS security settings" – Ben Franske Jan 30 '21 at 03:44
  • I think I've found a solution which involves clearing of some default certificates on the newer routers out of the box after creating a stronger keypair. Cisco documentation on this seems to be thin. I have some more testing to do but will try to write up an answer once I have the most succinct way to do this figured out. – Ben Franske Jan 30 '21 at 04:13

1 Answers1

0

After extensive testing I was able to figure this out. As far as I can tell it is not officially documented by Cisco for example their HTTP Services Configuration Guide still lists some of these steps as optional, but it appears that on newer hardware or software one of the optional steps has become mandatory.

In particular, older Cisco devices would automatically link the HTTPS server to a self-signed trustpoint when HTTPS was enabled. Although enabling HTTPS will still generate the keys, certificate, and trustpoint for you the HTTPS server no longer automatically uses that trustpoint for connections so you must manually tell the HTTPS server to use the correct trustpoint with the ip http secure-trustpoint command.

I suspect this is an unintentional bug introduced somewhere along the line because it still atuomatically does everything else for you including creating the trustpoint, the HTTPS server just doesn't automatically select the trustpoint it created as the one to use.

So, if you watch the terminal log carefully after running the ip http secure-server command on the router you will see some output like this:

r2(config)#ip http secure-server
CRYPTO_PKI: setting trustpoint policy TP-self-signed-3189949043 to use keypair TP-self-signed-3189949043% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 5 seconds)
*Jan 30 09:50:16.152: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named TP-self-signed-3189949043 has been generated or imported by crypto-engine
*Jan 30 09:50:16.243: %PKI-4-NOCONFIGAUTOSAVE: Configuration was modified.  Issue "write memory" to save new IOS PKI configuration

This will give you the name of the trustpoint that was created, in my case "TP-self-signed-3189949043".

Note that if you miss this message during the enabling of the HTTPS server you can find the trustpoint in the router's configuration after the fact.

The newly required step then is to tell the HTTPS server to use that trustpoint with the ip http secure-trustpoint TP-self-signed-3189949043 command (replacing the trustpoint name with yours).

After doing this browsers will be able to connect to the HTTPS server using the normal process for trusting self-signed certificates.

Note that this is unlikely to occur in a production environment because you must setup trustpoints if you are using certificates signed by a CA (as opposed to self-signed certificates).

Ben Franske
  • 511
  • 2
  • 11