01-08-2016 11:53 AM - edited 02-21-2020 10:30 AM
I work for a service provider company and helped out one of my colleagues today who had trouble with getting a newly installed C896VA-K9 router (running IOS 15.4) to authenticate with our public CA server via the internet. That is when I witnessed something very weird and illogical. I hope someone can make some sense of this...
So I SSH'd to the box, did a couple show commands and saw that the configuration was OK, the RSA key pair was in place and the trustpoint configured:
My_Router#sh crypto pki trustpoint status
Trustpoint MY_TRUSTPOINT:
Issuing CA certificate not configured.
Next enrollment attempt:
12 seconds
* A new key will be generated *
* Configuration will not be saved after enrollment *
State:
Keys generated ............. Yes (General Purpose, non-exportable)
Issuing CA authenticated ....... No
Certificate request(s) ..... None
The fact that the router did not authenticate the issuing CA yet was already unusual, as the router is configured with an event manager that automatically authenticates the CA, once NTP becomes synchronized.
When trying to manually authenticate the CA server with the command (config)#crypto pki authenticate MY_TRUSTPOINT, the waiting period was unusually long, and eventually the router returned the following syslog message:
%PKI-6-CERTRENEWAUTO: Renewing the router certificate for trustpoint MY_TRUSTPOINT
%PKI-3-SOCKETSELECT: Failed to select the socket.
I gave it several tries, but without luck. I even erased the trustpoint and configured it again, but the authentication kept failing. Then I did a "debug crypto pki transactions" to see what exactly happens in the background, and tried to authenticate once again. Strangely, this time the authentication was successful! After it I quickly enrolled and finally received my certificate from the CA.
I found it strange that after issuing a simple debug command the authentication succeeded, so I did it again from the start. I erased the trustpoint and the RSA key pair, and configured them once more. I tried to authenticate with the debug turned off; it didn't work. Then I turned the debug on and the authentication was successful!
I cannot figure out what happened there, because the whole thing does not make any sense for me.
The only thing that diverged from the default setting was the config register, which was set to 0x101 instead of 0x2102.
Might it be the cause of this weird behavior?
Any kind of help/information is much appreciated!
01-08-2016 12:41 PM
Smells like an IOS bug to me. I would try the newest release in that train.
01-09-2016 05:01 AM
Yes, that's definitely a possibility. Too bad that my company's policy doesn't allow me to use a different IOS version... Going to try it in a lab environment as soon as I get a chance!
Thank you for the tip
01-09-2016 10:39 AM
So you have this exact same time and the exact same IOS at other customers and this is working ok?
01-10-2016 11:51 PM
The IOS version depends on when the router was installed. The current IOS used for new installations is 15.4, as in this case.
I never had this issue before with other customer routers running on 15.4.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide