PKCS #12 import failed when reprovisioning old device

[trondaker]

Hi,

Have a lab-switch that we have cleared config on and re-discovered. Everything worked fine the first time, but after a inventory delete and config-cleanup, the re-provisioning of this device doesnt work anymore. It fails with this error:

Sep 9 06:48:23.581: %PKI-3-PKCS12_IMPORT_FAILURE: PKCS #12 import failed for trustpoint: sdn-network-infra-iwan. Reason: Failed to read PKCS12 from url: http://x.x.x.x/api/v1/trust-point/pkcs12/13605f8f-9b22-4695-b614-1a56a021731b/3fomgmu9u0bfiogkhar5cm3sbl

Sep 9 07:07:16.015: %PKI-6-TRUSTPOINT_DELETE: Trustpoint: sdn-network-infra-iwan deleted succesfully
Sep 9 07:07:16.015: PKI_SSL_IPC:
PKI trustpoint data record delete function handler invoked for trustpoint label: sdn-network-infra-iwan
Sep 9 07:07:16.015: PKI_SSL_IPC: Table record destroy is successful

PKI Config push failed for device.

It seems that the URL for the cert gives a 404 not found when trying a curl to that address - is this because the serial-number isnt cleared from the inventory somehow? Any way to get around this?

[Mike.Cifelli]

Please share additional information that may aide the community in better assisting:

-IOS version

-DNAC version

-Any other relevant information that may be helpful

 --Lastly, if this is a test switch, I would completely wipe the switch and start from scratch.  I have not seen this error in my experiences.

[trondaker]

Hi,

IOS on all devices is 17.3.3, DNAC 2.2.2.3. I have run a full wipe of the config, but maybe it related to an internal cert-issue in dnac? In that it sees the same switch-serial number and uses an old link to the trustpoint that doesnt exist anymore?

[alberx]

The same is happening to me. Just added a new switch to one stack (already in the fabric), and changed the IP address of the Loopback 0 interface.

Rediscovered OK, but the provision process fails with the same error "%PKI-3-PKCS12_IMPORT_FAILURE: PKCS #12 import failed for trustpoint: sdn-network-infra-iwan. Reason: Failed to read PKCS12 from url: http://10.200.8.XXX/api/v1/trust-point/pkcs12/1edb2f21-4868-4a67-a9ca-d05d4675c966/u2599u4479qsnchtb361ahhlhp    --> (the xxx is the IP of the DNAC server).

Any suggestions ?

Thanks.

[trondaker]

Seems to be some internal state that has to be cleared by TAC. I havent found a solution yet, and were at 2.2.3.4. The problem for us was in our lab, so didnt bother with opening a TAC-case, but they should probably be made aware.

[trondaker]

Actually, last night in some branch conversions, we had to wipe an already discovered device and put in a basic config to re-discover with different credentials. We didnt get any problems provisioning that device when it came back up - maybe it is fixed in 2.2.3.4? What version are you on @alberx ?

[alberx]

Hi trondaker.

my DNAC is 2.2.2.6 the recomended until one month ago.... and switches with 17.3.4.

[alberx · Accepted solution]

Finally I got it.

It was just that (i can not understand why) the switch lost the command "ip http client source-interface Loopback0". 

As the switch log failure was "Failed to read PKCS12 from url: http://10.200.8.XXX/api/v1/trust-point/pkcs12/1edb2f21-4868-4a67-a9ca-d05d4675c966/u2599u4479qsnchtb361ahhlhp" ,  and the DNAC had an error saying it was unable connect by https and to check certificates. I started to search in this way.

I found a bug for the WLC with similar problem (https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr98535?referring_site=ss&dtid=osscdc000283) and comparing configs of another devices, I realized this line was missing.

[trondaker]

Wow, well done - works here as well Thanks!

[Runtal]

A small addendum for this, I had the same problem, but source interface was correctly set.

However, the line "ip http client proxy-server XXXX proxy-port XXX" on our WLC forced them to try to download the certificate via proxy settings, which obviously failed as the DNA was on our local network.

So just delete this line temporarily, push telemetry settings in force mode and you're golden.