Certificate WebAuth in WLC5508 in HA SSO

[AdanCisco]

Hi

When uploading a .pem certificate in Security > Web Auth > Certificate . "file transfer error" appears.

In my tftp server it appears as sent successfully.

Should I enable "debug transfer tftp"? or it can be a problem in HA SSO environments?

# Note: The certificate is working on other controllers without HA

Software: 8.5.161.0

Thanks!

[Rafael E]

Hi Adan,

To be sure if file transfer is the problem enable on CLI: debug transfer all enable 

Start the transfer from GUI or CLI and confirm transfer is the problem 

Now, for SSO WLCs if you manage to load the certificate to the primary certificates are not sync between boxes so in case of a failover you might see problems depending on what is the certificate purpose. 

I would disable HA .. load certificate on both boxes and enable SSO back just to have real redundancy configured in your network.

[Rich R · Accepted solution]

You can also get the cert on both boxes by loading on primary then "redundancy force-switchover" then loading on secondary and then "redundancy force-switchover" so that you're back running on your primary WLC and both WLC have loaded the new cert. This avoids having to break HA-SSO.

[AdanCisco]

Hi!
I see this:
"High Availability (HA SSO) considerations:

As explained in the WLC HA SSO deployment guide, certificates are not replicated from primary to secondary controller in a HA SSO scenario. This means that you have to import all the certificates to the secondary before forming the HA pair. Another caveat is that this won't work if you generated the CSR (and therefore created the key locally) on the primary WLC as that key cannot be exported. The only way is to generate the CSR for the primary WLC with OpenSSL (and therefore have the key attached to the certificate) and import that certificate/key combination on both WLCs."

In URL: https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/109597-csr-chained-certificates-wlc-00.html#anc17

I understand that the HA must indeed be dismantled.

Thanks

[dannyngo99]

Hi Scott, Thanks very much for your helpful info. Just want to clarify the order of the cert installation. First question, we only need ONE new cert for BOTH controllers, correct?

Secondly,

the order of the cert installation.

1. install the new cert on primary (active unit) 

2. issue " Redundancy force-switchover" -->on the primary unit

3. the stand-by becomes the primary /active unit.

4. reboot the primary/active unit with the new cert ( which is now stand by)

5. install the same new cert on the new active unit and issue "Redundancy force-switchover" so that the old active unit become active ( assume both controllers are now in sync)

6. check to ensure all APs are now joined back to the active controller (which was the primary at the first place)

7. now reboot the second / old stand by unit

are these steps in correct order? Thanks again.

[Scott Fella]

@dannyngo99 The steps are correct. Just keeping mind how certificates work, you can use the same certificate as long as the end device successfully resolves the certificate.  In this case, you are most likely using the VIP as the IP and the hostname will not change because of SSO, so you can get away with one cert for both.  Some times you can also enter multiple SAN fields that allows you to add a cert to multiple devices, but that is not what you will be doing.  

Hope that helps.

[Rich R]

No those steps are not correct!  I explained it way up this thread ages ago - it's the marked solution!
You have an extra reboot on each WLC in your steps for some reason!
When you switchover the active unit reboots so why reboot again after that?
See Solved: Re: Certificate WebAuth in WLC5508 in HA SSO - Cisco Community

[dannyngo99]

Thank you very much for your reply and confirmation of my steps. Greatly appreciate it.

[AdanCisco]

Hi Rafael
I've activated the command: "debug transfer all enable" and this is the  answer (in case you can help me):

*TransferTask: Apr 24 11:51:30.279: [PA] Memory overcommit policy changed from 0 to 1
*TransferTask: Apr 24 11:51:30.279: [PA] RESULT_STRING: TFTP Webauth cert transfer starting.

TFTP Webauth cert transfer starting.
*TransferTask: Apr 24 11:51:30.280: [PA] RESULT_CODE:1

*TransferTask: Apr 24 11:51:34.401: [PA] TFTP: Binding to remote= IP TFTP Server
*TransferTask: Apr 24 11:51:34.795: [PA] TFP End: 5644 bytes transferred (0 retransmitted packets)
*TransferTask: Apr 24 11:51:34.795: [PA] tftp rc=0, pHost=10.60.13.100 pFilename=/X.pem
pLocalFilename=cert.p12

*TransferTask: Apr 24 11:51:34.922: [PA] RESULT_STRING: TFTP receive complete... Installing Certificate.
*TransferTask: Apr 24 11:51:34.922: [PA] RESULT_CODE:13

TFTP receive complete... Installing Certificate.
*TransferTask: Apr 24 11:51:38.925: [PA] Adding cert (5600 bytes) with certificate key password.
*TransferTask: Apr 24 11:51:38.932: [PA] RESULT_STRING: Error installing certificate.
*TransferTask: Apr 24 11:51:38.932: [PA] RESULT_CODE:12
*TransferTask: Apr 24 11:51:38.932: [PA] Memory overcommit policy restored from 1 to 0

I discard problems in the server TFTP^.

Note: I remember that this certificate is working in two other controllers without HA.

"As explained in the WLC HA SSO deployment guide, certificates are not replicated from primary to secondary controller in a HA SSO scenario. This means that you have to import all the certificates to the secondary before forming the HA pair."

When I try to undo the HA, it I confirm the result.

Thank you for your help.

[Rich R]

Most of our WLC are HA-SSO pairs and we have no trouble installing the certificates using the procedure I detailed above (pri - switch - sec - switch).  But we never use CSR from the WLC so the other piece you quoted which may be key is "The only way is to generate the CSR for the primary WLC with OpenSSL (and therefore have the key attached to the certificate) and import that certificate/key combination on both WLCs."  So the pem file you load on both should contain the cert (and root chain certs) and private key.

Nice summary at https://knowledge.digicert.com/solution/SO25990.html

And more lengthy: https://community.cisco.com/t5/wireless-mobility-documents/steps-to-create-and-upload-a-certificate-to-a-wireless-lan/ta-p/3113346

[Scott Fella · Accepted solution]

You don’t have to break SSO. You first install the certificates on the active controller. Then you issue a force failover which will make the standby active. Then you install the certificates on the new active controller. Then once the pair is in sync, you can issue another force failover and bring up you primary which you want active.
This method will not cause any downtime.

[Rich R]

Yes that's exactly what I said Scott :)

[Rafael E]

The certificate is fully received at the WLC.  WLC should install it whether in HA or not.

So, you can break HA (cisco doc) or follow the suggested methods from other post, that's fine,  but you will encounter the same certificate errors

I think you should focus on why the certificate is not being taken.

How was the CSR generated?

is this a full chained certificate? 

what WLC?

what code?

You said this certificate was successful in other WLC, what WLC, what code?

[AdanCisco]

Hi!

The problem was in the date of the controller.
It had the configuration modified by the bug CSCuq19142 (Wireless Access Points fail to connect to the Wireless LAN Controller) and command "config ap cert-expiry-ignore {mic|ssc} disable". Once the date was changed the certificate worked.

I used the "force-switchover redundancy" command and it was not a problem, I just had to restart the APs that took the date of the previous certificate.

Now I keep fighting on google chrome since I don't get the login page (customized by html) but in other browsers (Edge & Firefox) I can access it. I flush de DNS in CMD and clear history.

Thank all