WLC 4402 - Certificate & URL

[vmody]

WLC 4402

Software Version 4.1.185.0

PART ONE - CERTIFICATE:

I have a certificate that I am trying to import into WLC. When using "transfer download start" I get the following error: "error installing certificate".

When I use "debug pm pki enable" functionality I see this as the cause of the above error: "sshpmDecodePrivateKey: private key decode failed..." and "sshpmAddWebadminCert: key extraction failed."

What do I need to do to resolve this error? I followed all the instructions regarding using openssl to request a csr.

PART TWO: URL

When a user gets redirected to authenticate they get "https://1.1.1.1 as the URL and they get the login page. When I change the DNS host name in 'virtual' interface to https://wifi.ourdomain.com the user gets a "Page not found" instead of a login page? I cannot add a DNS entry to 1.1.1.1 in our DNS servers (does not recognise 1.1.1.1 as valid IP) so what do I need to do?

Thanks!

Vikram

[mruhenkamp]

Did you by chance get your Certificate problem resolved? I am having the exact same issue.

[Scott Fella]

You have to make sure you set a password on the pem file you are trying to upload and enter the password when you tftp the webauth cert.

After you successfully upload the cert to the WLC then go to the VIP Interface and enter the wifi.ourdomain.com in the DNS Name box. You can change the Virtual IP to a private IP that you are not using in your network... 192.168.253.x or something like that. The certificate DN=wifi.ourdomain.com and the VIP DNS name wifi.ourdomain.com has to resolve of else you will get the "Page not found".

[securityfirst]

We've got same issue here with 4.2.61.

Certificate Password is set and verified, cert is PEM encoded, and not chained.

show debug transfer all enable

show debug pm pki enable

Be aware that each unsuccessfull try force you to reset the controler. After many tries we've noticed that the WLC keeps installing the same certificate, even if you tftp a new one, until you do reset the device.

Proof:

TFTP Webauth cert transfer starting.

Locking tftp semaphore, pHost=192.168.30.20 pFilename=wifiguest.tr

Semaphore locked, now unlocking, pHost=192.168.30.20 pFilename=wifiguest.tr

Semaphore successfully unlocked, pHost=192.168.30.20 pFilename=wifiguest.tr

TFTP: Binding to local=0.0.0.0 remote=192.168.30.20

TFP End: 2323 bytes transferred (1 retransmitted packets) <--- actual size of certificate file

tftp rc=0, pHost=192.168.30.20 pFilename=wifiguest.tr pLocalFilename=cert.p12

RESULT_STRING: TFTP receive complete... Installing Certificate.

RESULT_CODE:13

TFTP receive complete... Installing Certificate.

Adding cert (2303 bytes) with password "" <-- size not good, password blank?

sshpmAddWebauthCert: extracting private key from webauth cert; pwd: <>.

sshpmDecodePrivateKey: private key decode failed...

sshpmAddWebauthCert: key extraction failed.

RESULT_STRING: Error installing certificate.

RESULT_CODE:12

Error installing certificate.

My guess is that the certicate password is not set (even if we initiated transfer webauth cert password), resulting in a decoding error. Perhaps that the blank password in logs is a security, but we also got an error when using the web method to upload web auth certificate saying "error setting web auth cert password" or something like that....

[DJCanuck1_2]

Has anyone resolved the DNS registration issue to 1.1.1.1? I have generated an internal cert from our root CA and have this working with the IP address 1.1.1.1 internally. My question is regarding registering a public certificate to the address 1.1.1.1. During the web authentication, we would like the end user not to be prompted with the WLV certificate warning by using a publicly trusted cert. Is this possible for the IP 1.1.1.1?

[Scott Fella]

When you request a certificate, you specify the DN to a DNS name you will resolve to 1.1.1.1. This will work. If you don't want the user to see the 1.1.1.1, use a private IP address that you currently are not using and resolve the DN and DNS to that IP.

[DJCanuck1_2]

So are you saying that the WLC virtual interface can use an IP other that 1.1.1.1? I didn't think you could change this....

[Scott Fella]

yes you can... just make sure if you have any other controllers in the mobility group that all have the same VIP address.

[craig.eyre]

Sorry to bud in but if I read this right regarding the same IP for each VIP in a mobility group. Can you use the same ssl certificate for say 3 wlc's in the same mobility group?

Craig

[Scott Fella]

Yes you can. For example, if you have 2 guest anchor controllers, you can use the same ssl cert for both the guest controllers. You just have to make sure the VIP is the same and the DNS Name is the same.

[craig.eyre]

Thanks Fella,

One more question, do I need to create an actual DNS record on our dns server for the new private ip address for the VIP.

E.g. If I change from 1.1.1.1 to 192.168.1.1 and add wifi.bob.com. Do I need a dns entry on our dns server or do I just need to certificate to match my changes?

Thanks again.

[Scott Fella]

When you create the CSR, you have a CN field that equals to wifi.bob.com. You have to resolve that name to the VIP. If you don't, you will get the certificate error.

[shane.hudson]

So how DO you resolve it? I assumed the virtual interface was not in any way "connected" to any physical LAN. Is "naming" the virtual interface on the controller enough? Or do you need to be able to route to a DNS server somehow? I guess I'm a bit confuzzled...

[craig.eyre]

Shane,

The virtual interface is in essence a dummy interface so to speak. I assume that once your wireless clients get their dhcp information that they get your local dns servers as well?

I just created and entry on the dns server for the "virtual" interface e.g. 10.1.1.1 dns name wifi. This should append to your normal domain name like wifi.bob.com.

On the controller just change the virtual interface to 10.1.1.1 dns name wifi (or whatever you decide on) apply it and then you'll need to restart the controller.( you could wait to restart as you need to restart after you apply the new certificate)

Go get a SSL cert from either RapidSSL, Thawte, Verisign etc.... and follow the following document to make and apply the cert.

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00806e367a.shtml

You can get a test cert from thawte to make sure that you created everything right before you purchase the correct one. Don't want to have to buy a second cert if you mess up the first one.

HTH

Anymore questions just let me know.

Craig

[shane.hudson]

>I assume that once your wireless clients get

>their dhcp information that they get your

>local dns servers as well?

No, they get the DNS servers of our ISP, on their way through our custom-written, installed-on-the-controller portal. I guess I should have mentioned that this is a public-access municipal wifi zone. So of course we don't have the ability to create a mapping in that DNS, and 1.1.1.1 (the viritual IP) isn't public anyway.

It makes sense to create a cert for the virtual interface name, but I guess I have no way for the cert to reverse lookup for verification...