03-15-2023 10:10 AM - edited 03-15-2023 02:29 PM
Hi,
We are currently evaluating a Cisco AIR-AP1800S-E-K9, but this is failing to be claimed in Cisco DNA.
AP Running Image : 2.2.1.3
Primary Boot Image : 2.2.1.3
Backup Boot Image : 8.8.259.0
DHCP Option 43 configured to use: option 43 ascii "5A1N;B2;I"DNA Server IP";J80;K4"
The Sensor goes away to be claimed, but fails with the following:
2023-03-15 17:01:05,974 - pnp.infra.network.HTTPConnClient - DEBUG - PNP requests with url: //ServerIP:443/pnp/WORK-REQUEST
2023-03-15 17:01:05,997 - pnp.infra.network.HTTPConnClient - ERROR - Retrying Work-Info Request in 15 seconds...
Traceback (most recent call last):
File "/usr/lib/pnp/infra/network/http_conn_client.py", line 253, in send_work_info_request
"pnp/WORK-REQUEST")
File "/usr/lib/pnp/infra/network/http_conn_client.py", line 149, in _send_request_helper
f = urllib2.urlopen(req, context=self.ctx, timeout=30)
File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
raise URLError(err)
URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] unknown error (_ssl.c:727)>
2023-03-15 17:01:21,018 - pnp.infra.Profile.1 - ERROR - Failed to send Work-Info request
We have the IP Address in the SAN Cert used in DNA, is there anything that could be stopping the sensor to be claimed?
Thanks, James
07-20-2023 12:49 PM
Did you ever get this figured out? I'm having the same issue.
07-20-2023 02:12 PM
There are plenty of reasons why certificates aren't valid. Be sure to carefully follow instructions here: https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/hardening_guide/b_dnac_security_best_practices_guide.html#task_zpl_4c2_rbb
Newer versions of DNA have a "generate CSR" button that should make the process much simpler (shown in the doc above)
07-21-2023 01:08 AM
Hey,
I had a similar problem a few days ago.
In the past, I generated a System Certificate using OpenSSL as documented in the Security Best Practices Guide. Sensors were onboarded correctly into DNAC.
More recently, I had to change my DNAC certificate to accommodate DNAC IP readdressing I had to do. This time I used the "Generate CSR" button from DNAC WebUI. And Sensors became unreachable from DNAC perspective.
It appears that when using the "Generate CSR" button, the resulting CSR has the SANs DNS list reordered randomly. As stated in the Security Best Practices Guide, it says:
The first DNS entry in the alt_names section should contain Cisco DNA Center's FQDN (DNS.1 = FQDN-of-Cisco-DNA-Center
).
Cisco should fix this.
After recreating a CSR using OpenSSL and uploading the new certificate into DNAC, Sensors were able to be fully functional again.
Hoe this helps.
Sylvain.
08-03-2023 07:36 AM
Thanks for the replies. I actually do have FQDN followed by the enterprise IP and node IP. Weirdly PNP works fine for switche's even my WLC but it fails during the onboarding process of AP's C9120AXI-B to be exact.
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