2

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
Improve this question
1
1

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.

In fact, the IOS 16.9 command reference guide states "Command Default: The HTTPS server uses the trustpoint configured when you use the primary command. If a trustpoint is not configured, the HTTPS server uses a self-signed certificate." and "If this command is not used, the server will attempt to use the certificate associated with the primary trustpoint." These indicate that when a self-signed certificate is the only certificate on the router (as it is out of the box after enabling the HTTPS server) the ip http secure-trustpoint command should not be required.

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

Improve this answer
4
  • As I suggested. You can actually have multiple trustpoints, so you need to distinguish between them. This is actually in the Cisco documentation. – Ron Maupin♦ Jan 30 at 16:21
  • Yes, I can understand why you would need that. However, if you only have one trustpoint Cisco used to automatically select it for the HTTPS server and it seems they no longer do so though I am unable to find any documentation that this change was made. In other words, for people like myself relying on that behavior there is no way to know it had changed. I still can't find any resources online whatsoever that indicate you are required to select a particular trustpoint, and everything else, including the trustpoint itself, is still setup automatically so I suspect it's a bug. – Ben Franske Jan 30 at 16:28
  • The need to do it I found in the IOS 15M&T, so it may hav3e changed from 12 to 15. You really need to check more recent documentation when you find such problems. – Ron Maupin♦ Jan 30 at 16:30
  • 1
    FWIW I was looking at the IOS XE 16.9 documentation (as that is what I am running) and didn't see it clearly there. I'll have to dig one out and double check on one of my IOS 15 devices, but I'm pretty sure they worked without setting a trustpoint when using a self-signed certificate. – Ben Franske Jan 30 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.