Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Steps to Create and Upload a Certificate to a Wireless LAN Controller

1. Generate a private/public key pair.

2. Generate a CSR.

 

(this is the information that you want to be sent to clients when they ask about your object's identity)

(so, this is the same information that you want to be processed by the CA to make the CSR info as your object's Online-ID)

(This Online-ID is nothing but the CERTIFICATE)

 

(While submitting the CSR to the CA, if you used the password, then please provide the same to the CA)

 

3. Submit the CSR to a CA.

4. Retrieve the certificate-ingredients that the CA produces, and sends it back to you.

5. Combine/Bundle the certificate-ingredients (that CA sent) with the private key(that you had) into a pkcs12 file.

6. Convert the pkcs12 file to a privacy enhanced mail (PEM) encoding file.

7. Upload the new third-party certificate (.pem file) onto the WLC.

 

4. =

 

(you either get it via email or you need to login to CA's site)

(when you get the certificate ingredients, please ensure you have the root, intermediate and device certificate)

(you can call these as certificate-ingredients are you will have to process them and get a single certificate out as the processed output)

 

Once, you have get those certificate ingredients, you need to ensure which is what. Open each ingredient file in a notepad file, and copy copy the contents of each

 

ingredient-file and paste the same in a new text file, in the following format:

 

------BEGIN CERTIFICATE------

*Device cert*

------END CERTIFICATE------

------BEGIN CERTIFICATE------

*Intermediate CA cert *

------END CERTIFICATE--------

------BEGIN CERTIFICATE------

*Root CA cert *

------END CERTIFICATE------

 

5. =

 

Save that new text file as , say, all-certs.pem

 

6. =

 

Combine the CA.pem certificate with the private key, and then convert the file to a .pem file.

Issue this command in the OpenSSL application:

 

openssl> pkcs12 -export -in CA.pem -inkey ' mykey.pem ' -out "  CA.p12   " -clcerts    -passin pass:check123 -passout pass:check123

 

                                          !--- This command should be on one line.

 

openssl> pkcs12             -in                      '  CA.p12   ' -out " final.pem "                    -passin pass:check123 -passout pass:check123

 

[

In this command, you must enter a password for the parameters -passin and -passout .

While loading the Cert into the WLC, the password that is used on WCL, must be the same as was configured for the -passout parameter.

(In this example, the password that is configured for both the -passin and -passout parameters is check123)

]

 

[

To convert the all-certs.pem file into pkcs12 file, you need to ensure that the your object's private key (mykey.pem) and public key (all-certs.pem) must be in the same

 

folder, and that folder should be the one that has OpenSSL.exe in it. Usually, this folder is C:\Program Files\GNU\Win32\OpenSSL\bin

]

 

[

If, OpenSSL does not generate CA.p12 or final.pem, we can verify the following:

Verify that the all-certs.pem file has certificates in the following order: D evice, I intermediate, R oot.

Verify that the mykey.pem file is the same that got generated during the creation of CSR.

Verify that if the optional password was set within the CSR, the password was provided to the CA(while requesting the Digi-Cert).

]

 

7.=

 

[Different platforms and devices require SSL certificates to be converted to different formats. For example, a Windows server exports and imports .pfx files while an

 

Apache server uses individual PEM. We can convert the digi-certs in different formats per https://www.sslshopper.com/ssl-converter.html]

 

Now, we put the final.pem (Digital Certificate) in the Root Diretory of the TFTP Server, and load the same into the WLC.

(it is convenient to put the digi-cert in the root dir of the tftp, so that the Certificate File Path in the GUI of the WLC can be set as '.')

 

Loading of cert can be either with GUI or CLI of the WLC.

 

GUI Steps:

Secuirty->WebAuth->Certificate

Check the box -> "Download SSL Certificate", and fill the details.

 

CLI commands to load the certificate into the controller

 

transfer download serverip <IP of server>

transfer download datatype webauthcert

transfer download filename <cert filename>

transfer download mode tftp

debug transfer tftp enable

transfer download start

 

If loading of the Digital Certificate is successful, you need to reboot the WLC.

 

[

If the Digi-Cert cannot be loaded into the WLC :

debug transfer all enable.

verify that password is used.

]

 

After the submission of the CSR to the CA, we at times, get the files from the CA which represents the public key , however we do not know which one is the Root or Intermediate or the Device certificate. Say, we have these files in .crt format. Now, when we open these files we should follow the following:

 

In the Root certificate, 'Issue To' and 'Issued By' should be same, which will represent the ROOT CA.


In the Intermediate certificate, 'Issued By' should be the Root CA, and 'Issue To' should be the Intermediate CA.


In the Device certifiate, 'Issued To' should be the Device and 'Issued By' should be the Intermediate CA.

Comments
Cisco Employee

Who is a CA?

What is a certificate ?

What is SSL ?

What is HTTPS ?

=======================

If , the sender and receiver get validated to be indeed what they claim/say they are, then the receiver can treat the sender , as indeed what the sender says he is.

This validation of an entity is done by issuing a certificate to the entity by his 'CA' (who certifies that the object is what he says that he is, via 'his' key).

So, A's certificate will be A's public key (bearing the mask of the CA)<->certified by a CA, or a certified public key of A.

Thus, a CA maintains the mappings between the entities and their corresponding public keys (PKI)

A certificate of a WLC is therefore similar to an Online ID for the WLC, identifying the WLC's apache webserver to the client(web browser).

OK. So now , we have two objects, and the mechanism between them in place, by using which these objects can not only identify each other but also encrypt the data they

exchange between them.

What if the objects ..

[Client Browser's computer and Computer hosting the Web Server of the website (that is being accessed by the Client Browser) ]

.. are separated across the Internet(which is a collection of many networks) ? In this case, we need a protocol [in addition to SSL (that only helps in securing data

between objects)] to transfer data between objects, via Internet.

To tranfer the information:

When the objects (not identified by their certificates) transfer information over Internet, they use HTTP  to transfer the information.

When the objects (    identified by their certificates) transfer information over Internet, they use HTTPS to transfer the information.

So, https works in tandem with SSL Certificates. Or, HTTPS = HTTP + SSL.

These certificates can either be issues by the objects themselves or via a third party CA. Eg: Verizon, Go Daddy, etc.

The CA may be common (unchained certs) or un-common(chained certs) between the entities in communication.

Cisco Employee

EXAMPLE:

========

A client(browser) tries to browse a website.

A user tries to get into the GUI of the WLC

Website(GUI) is hosted on a server (Apache Server in WLC)

Client asks the server: Who are you ?

The Server (web server) sends its PublicKey(as his identifier) to the ClientBrowser

The WLC (Apached Web Server) sends its PublicKey(as his identifier)  to the User(User's Web Browser)

The Client Browser checks if the signature of the signitory(CA) of the digital signature ( Server's public key), is available with the Client Browser.

If yes, the Client Browser does     deem the WebServer to be authentic (thus, does not throw any Warning Message)

If no , the Client Browser does not deem the WebServer to be authentic (thus,          throws a  Warning Message)

When customer opens his browser to gain access to the GUI of the WLC , he gets a warning because the Apache Server of the WLC sends its own self-assigned public-key of

the WLC. Now, as the ClientBrowser will not able to recognize hostname of the WLC, the client browser will throw warning message.

Cisco Employee

DNS Server Configuration:

=========================

All that a DNS Server requires is:

- to have the mapping for the Hostname(FQDN) [ mentioned in the Virtual Interface of the WLC] to the IP Address of the VIP of WLC.

  ( This mapping of the virtual ip address and fqdn , in the DNS is called A-Record of the DNS database )

- to have the DNS point to your ISP or Internet DNS servers, for everything else.

[

The Guest clients must use the Internal DNS servers, where the Internal DNS servers must have an A record for the FQDN, pointing to the IP Address of the Virtual  Interface of the WLC (most commonly , 1.1.1.1 )

]

if using anchor and foreign setup, then anchor should be referred to for dns entries.

https://supportforums.cisco.com/videos/1871

https://supportforums.cisco.com/videos/1878

DNS Server Location:

====================

The dns server can be

-in the external network

-in the internal network

-in the DMZ

Scenario:

=========

                          Internet (External Network)

                               |

Internal Network ------       F/W   ------------------      DMZ (DNS is here)

6908
Views
5
Helpful
3
Comments