We have an internal certificate authority and I can make my switches use it for managing them via HTTPS (ip http secure-server) in both a regular browser and in Cisco Network Assistant. I want CNA to work with our switches without certificate errors or warnings, so we're not conditioned to "always trust" untrusted https servers and trust some non-company server by mistake.
I can create and sign certificates generated by switches running IOS 12.2(55) and later. When visited with a browser that has the internal CA certificate trusted, I can browse switches without certificate warnings or errors. In Cisco Network Assistant, this is almost true, with only the CA certificate not trusted. I can fix that by editing the database of trusted CA certs (packages / runtime-1.42 / security / cacerts); there are a few tools available for managing Java-based certificate databases.
The only remaining snag is when I try to build a community in CNA, CNA insists on connecting by IP address instead of by host name. This is fine; the CA certificate server I use supports subject alternative names and my CA-trusting browser will accept all of these as valid:
https://switch.example.com
https://switch
https://10.10.10.254
CNA will accept the first two examples (switch.example.com and switch) but not the IP address. It will complain that the host name does not match the certificate.
I know some hostname resolvers like to use different punctuation for IP-based browsing. Some prefer putting IPs in brackets and will resolve [10.10.10.254] instead of 10.10.10.254, for instance. I tried adding both of these to the list of subject alternative names, without CNA accepting them. Is there a magic format that CNA uses that I can make a matching subject alternative name for?
A little searching revealed that Java https clients dislike IP-based URLs. Then how about building a community using hostnames instead of IP addresses? I can't seem to do this; CNA will obtain the IPs and use those, and subsequently complain about every switch's certificate.
