WLC C9800 - Unable to import pfx Certificate

[stephendrkw]

Hi all, 

I'm unable to import a PCKS12 Device Mgmt certificate into my Wireless Controller C9800, unlike my previous 5508 WLC's there are now Trustpoints etc involved.

The way we generate Certificates is we do not generate a CSR from the Device, rather input device details manually on a Cert Server GUI and this generates a.pfx file we download. We would import this .pfx onto the device and bang! Cert installs successfully just like on my 5508's! 

C9800 log:

Oct 25 08:23:37.190: CRYPTO_PKI: status = 0x705(E_INPUT_DATA : invalid encoding format for input data): Imported PKCS12 file failure
Oct 25 08:23:37.192: %PKI-3-PKCS12_IMPORT_FAILURE: PKCS #12 import failed for trustpoint: C9800.hello.com.pfx. Reason: Failed to import pkcs12 context

I don't want to connect to our CA Server as there are so many hurdles internally to use SCEP. Is there a way to import a .pfx into C9800 directly without a Trustpoint. Every time I create a Trustpoint, C9800 forces me to authenticate to a CA Server. Also, I am surprised the logs are complaining about invalid encoding format, aren't p12 and pfx are the same (PCKS#12) depending how your server generates them.

[stephendrkw]

"debug pki transaction" ouput below, to me this indicates that the import pfx is trying to use the Cisco Self-Signed Trustpoint and failing?

Oct 25 09:24:56.260: CRYPTO_PKI: Rcvd request to end PKI session A3FE3.
Oct 25 09:24:56.260: CRYPTO_PKI: PKI session A3FE3 has ended. Freeing all resources.TP-self-signed-146588143:unlocked trustpoint TP-self-signed-146588143, refcount is 0
Oct 25 09:24:56.309: CRYPTO_PKI: Initializing renewal timers
Oct 25 09:24:56.312: CRYPTO_PKI: (A3FE5) Session started - identity selected (TP-self-signed-146588143)xTP-self-signed-146588143:refcount after increment = 1
Oct 25 09:24:56.312: CRYPTO_PKI: Begin local cert chain retrieval.
Oct 25 09:24:56.313: CRYPTO_PKI: Done with local cert chain fetch 0.
Oct 25 09:24:56.313: CRYPTO_PKI: Begin trustpoint info get.
Oct 25 09:24:56.313: CRYPTO_PKI: Successfully got trustpoint info.
Oct 25 09:24:56.313: CRYPTO_PKI: (93FE6) Session started - identity selected (TP-self-signed-146588143)TP-self-signed-146588143:refcount after increment = 2
Oct 25 09:24:56.313: CRYPTO_PKI: Begin local cert chain retrieval.
Oct 25 09:24:56.313: CRYPTO_PKI: Done with local cert chain fetch 0.
Oct 25 09:24:56.313: CRYPTO_PKI: Rcvd request to end PKI session 93FE6.
Oct 25 09:24:56.313: CRYPTO_PKI: PKI session 93FE6 has ended. Freeing all resources.TP-self-signed-146588143:unlocked trustpoint TP-self-signed-146588143, refcount is 1
Oct 25 09:24:56.313: CRYPTO_PKI: Rcvd request to end PKI session A3FE5.
Oct 25 09:24:56.313: CRYPTO_PKI: PKI session A3FE5 has ended. Freeing all resources.TP-self-signed-146588143:unlocked trustpoint TP-self-signed-146588143, refcount is 0
Oct 25 09:24:56.738: CRYPTO_PKI: Copying pkcs12 from bootflash:C9800.hello.com.pfx

Oct 25 09:24:56.849: CRYPTO_PKI: status = 0x705(E_INPUT_DATA : invalid encoding format for input data): Imported PKCS12 file failure C9800.hello.com.pfx:PKCS #12 Import into trustpoint failed.
Reason - Failed to import pkcs12 context
Oct 25 09:24:56.850: %PKI-3-PKCS12_IMPORT_FAILURE: PKCS #12 import failed for trustpoint: C9800.hello.com.pfx. Reason: Failed to import pkcs12 context
Oct 25 09:24:56.894: CRYPTO_PKI: (A3FE7) Session started - identity selected (TP-self-signed-146588143)xTP-self-signed-146588143:refcount after increment = 1
Oct 25 09:24:56.894: CRYPTO_PKI: Begin local cert chain retrieval.
Oct 25 09:24:56.894: CRYPTO_PKI: Done with local cert chain fetch 0.
Oct 25 09:24:56.894: CRYPTO_PKI: Begin trustpoint info get.
Oct 25 09:24:56.894: CRYPTO_PKI: Successfully got trustpoint info.
Oct 25 09:24:56.894: CRYPTO_PKI: (93FE8) Session started - identity selected (TP-self-signed-146588143)TP-self-signed-146588143:refcount after increment = 2
Oct 25 09:24:56.894: CRYPTO_PKI: Begin local cert chain retrieval.
Oct 25 09:24:56.894: CRYPTO_PKI: Done with local cert chain fetch 0.
Oct 25 09:24:56.894: CRYPTO_PKI: Rcvd request to end PKI session 93FE8.
Oct 25 09:24:56.894: CRYPTO_PKI: PKI session 93FE8 has ended. Freeing all resources.TP-self-signed-146588143:unlocked trustpoint TP-self-signed-146588143, refcount is 1
Oct 25 09:24:56.894: CRYPTO_PKI: Rcvd request to end PKI session A3FE7.
Oct 25 09:24:56.894: CRYPTO_PKI: PKI session A3FE7 has ended. Freeing all resources.TP-self-signed-146588143:unlocked trustpoint TP-self-signed-146588143, refcount is 0

[Karsten Iwen]

PKCS12 and PFX is practically the same.

How did you do it? I just imported a PFX and it worked as expected:

1. Under PKI -> Security -> PKI Management -> Add Certificate -> Import PKCS12 the PFX is imported.
2. Under Administration -> Management -> HTTP/HTTPS/Netconf/VTY the new HTTP Trust Point is selected.
3. You get logged out and the new certificate is used.

You can check the PFX with openssl and you shouldn't have any errors there:

openssl pkcs12 -info -in cert.pfx

[stephendrkw]

openssl check - all ok

I tried via SCP rather than HTTPS still the same issue. I'm carrying out the same steps as yourself.....wondering if this is a bug?

[Karsten Iwen]

Are you running at least a Cisco suggested version like 17.6.4? When running into problems, upgrading to a suggested version is typically a good idea.

[stephendrkw]

I'm running:

Cisco IOS XE Software, Version 17.06.04
Cisco IOS Software [Bengaluru], C9800 Software (C9800_IOSXE-K9), Version 17.6.4, RELEASE SOFTWARE (fc1)

[Karsten Iwen]

Ok, that is the suggested release. I would open a TAC case then.

[stephendrkw]

I have opened a TAC

[Arshad Safrulla]

Refer to the below document, Generate and Download CSR Certificates on Catalyst 9800 WLCs - Cisco

[Rich R]

This is almost definitely because your cert package is not as specified in the guidelines @Arshad Safrulla linked to.
Have you included the full certificate chain? (Root + intermediate + WLC cert and key)
See the section starting "If you run the command openssl pkcs12 -info -in <path to cert> and only one certificate with one private key displays, it means the CA is not present. As a rule of thumb, this command ideally lists your whole chain of certificate. It is not required to include the top root CA if it is known by the client browsers already."

[stephendrkw]

We only have the certificate and the private key in the pfx 

I imported the RootCA and SubCA into PKI Management/Trustpools on the GUI which imported fine. shouldn't this be enough so when the pfx is uploaded C9800 can see the RootCA and SubCA and process the certificate?

[Rich R]

No I don't think so.  We've only ever had it work with the full chain (no problems with that) and the documentation is clear that at the minimum it should include the intermediate.

[stephendrkw]

I combined the RootCA and SubCA, pfx into one pfx. So I now have a full chained Certificate. 

After I was able to import the pfx file successfully, this also added the Chain to the Trustpools, created a new Trustpoint and a new Key Label. However, when I configured HTTP to use my new Trustpoint, HTTP Service restarted and my browser showed "does not have a Certificate-SSL error"!!!! Then had to go to the CLI remove new Trustpoint and configure Cisco Self-signed  Trustpoint to regain GUI access............seem to be getting close! Awaiting on TAC response.............

Oct 28 08:19:21.833: %PKI-6-TRUSTPOINT_CREATE: Trustpoint: C9800new.pfx created succesfully
Oct 28 08:19:21.836: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named C9800new.pfx has been generated or imported by pki-pkcs12
Oct 28 08:19:21.862: %PKI-6-PKCS12_IMPORT_SUCCESS: PKCS #12 import in to trustpoint C9800new.pfx successfully imported.
Oct 28 08:19:21.899: %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as * on vty1
Oct 28 08:19:49.509: %SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as * on vty1
 

[stephendrkw]

Ok, with the TAC Engineer, we tried numerous things, same problem, no cert, like remove Trustpoint, Key label and re-applied etc. We rebooted the wlc and noticed upon reboot, the WLC used the old software version, so I upgraded again to 17.6.4 and rebooted and applied "Commit" after the reboot which I didn't do last time hence the fall back to the old version 17.6.3 (you cannot change the boot statement like on a router/switch rather install same package again, a pain). After all this, we performed a clean on the Trustpools, saved and rebooted the WLC again. Then imported the PKCS12 full chain certificate again, and suddenly everything worked after the HTTPS restart, certificate valid. Surprising, yes! Then on the other new C9800 WLC we did the same, but no reboot. All we did on this WLC was cleaned the Trustpoints, without even importing anything. So what was the problem, a possible bug the TAC thinks............well your guess as good as mine! At least I now have validated Certificates! But getting back to previous posts, yes you should just be able to import the .pfx full chain without any issues at all. My only thinking was that possibly when I imported the 1st time, something with the Trustpools was screwed. Who knows!

[Rich R]

Agreed. I suspect that when you imported the certificates separately that got it into some sort of state.  Did TAC confirm that the certificate should be full chain or did they say the separate cert approach was supported?  If it's not supported that means it's never been tested and therefore could have unpredictable results.