Google Chrome will not accept any cert without SAN field in the cert which we don’t have that when we do the CSR from the WLC.
Some CA allow to insert SAN fields but will cost a lot more.
also, As explained in the AireOS WLC HA SSO deployment guide, certificates are not replicated from primary to secondary controller in a HA SSO scenario.
so you have two options:
Option 1
With this option we will generate the CSR file from the WLCs (Active and Standby in case HA SSO):
Pros:
1) The advantage with this option is that the key is generated on the WLC and never leaves the WLC thus is never exposed to the outside world.
Cons:
1) Need to generate the CSR file from both Active and Standby WLCs "in HA SSO case".
2) Need to have two separate certificates from public third party CA.
3) This method does not allow to configure Subject Alternate Name (SAN) in the CSR, as a workaround, some CA allow to insert SAN fields at signing time, this has to be done to insure that Chrome clients can see the portal with this cert because Chrome version 58 and later does not trust the Common Name of the certificate alone and requires Subject Alternate Name (SAN) to also be presented.
4) More expensive because you will need two certificates with SAN config.
5) In case of RMA, the new WLC need to have the same above steps.
6) WLC Virtual interface “DNS Host Name” need to be configured and this name has to match the common name in the CSR file. DNS team has to populate that name in the DNS so clients will be able to resolve that name even from public DNS servers “if Guests will be using public DNS Servers”, although, the portal itself will not be showing for anyone in the internet except those will be connected locally.
Option 2
With this option we will generate the CSR file from the OpenSSL program:
Pros:
1) Generating the CSR for the primary WLC with OpenSSL and therefore the key will be attached to the certificate and can be imported "that certificate/key" combination on both WLCs.
2) One certificate needed from the public third party CA instead of two for the HA pair.
3) This method allows to configure Subject Alternate Name (SAN) in the CSR file.
4) Less expensive because you will need one certificate.
Cons:
1) Less secure than option 1 because the key will be exposed to the outside world. (example: The PC that will be used with the OpenSSL will have a copy of the certificate private key)
2) Installing OpenSSL.
3) In case of RMA, the new WLC need to have the same above steps.
4) WLC Virtual interface “DNS Host Name” need to be configured as previously explained.
General Notes for both above options:
1) if you already have the WLCs in HA then you can do either the below:
a) Break the HA completely to install the certificate on both WLCs and reform the HA, or
b) Issue a command redundancy force-switchover on Active controller, when complete the certificate installation do that command again to switch to the Active one again.
2) Using the local WebAuth need to be combined with enabling HTTPS redirection feature or you will see problems, which mean the WLC has to run 8.8.130.0 or 8.10.x code. (this is for WLC performance reasons which was implemented from WLC code 8.7 and later).
3) A certificate warning is unavoidable in case the client request to open a web page manually to get to the AUP portal because if the client requests any URL (such as https://www.cisco.com), the WLC still presents its own certificate issued for the virtual interface IP address. This will obviously never match the URL/IP address requested by the client and the certificate will not be trusted unless the client forces the exception in the browser. Most today’s client’s devices (Smartphones or PCs) have a way to check that using their hidden websites to check connectivity, for example, Apple iOS will check with Apple website dedicated for this purpose (http://captive.apple.com/hotspot-detect.html) to present to the user the login portal (AUP portal), this is done by http traffic. Same thing for Firefox, (http://detectportal.firefox.com/success.txt) and similar method and links for other browsers, in these “http” cases the client will not see certificate error.
Openssl:
You can download and install Openssl version 1.1.1h from the internet, it is free.
After installing OpenSSL on a PC, go to the OpenSSL location (for example:C:\OpenSSL-Win64\) And then open the “cnf” folder inside the “bin” folder and right mouse click on openssl.cnf file and open it with Notepad or better with Notepad++ (Notepad++ is free also)
Make these important changes:
1) Uncomment req_extensions = v3_req line
2) Under [ v3_req ] Section add:
subjectAltName = @alt_names
[alt_names]
DNS.1 = anyname.yourcompanyname.com
DNS.2 = anyname2.yourcompanyname.com
Note: you can have one name or multiple names in above, so if you have multiple WLCs and wants all of them using the same WebAuth cert you need just one name and then from the DNS resolve that name to your virtual IP address (which is the same for all WLCs), example anyname.yourcompanyname.com = 192.0.2.1
Note: (((VERY IMPOTANT))): One of the DNS names above "which they are the SANs" MUST be the same name as the CN (Common Name) that will be used when generating the CSR, this is important for google chrome clients.
3) save the file
4) open the “bin” folder and right mouse click on openssl.exe and click “run as Admin”
5) Generate the CSR with:
req -out anyname.pem -newkey rsa:4096 -nodes -keyout anyname-key.pem -config "C:\OpenSSL-Win64\OpenSSL-Win64\bin\cnf\openssl.cnf" <-- replace the windows path and then complete all the required info
6) Make sure to keep your private key file secure.
7) To verify the information and the SANs, close the openssl and reopen it again (needed to avoid a bug in Openssl version 1.1.1h)
After opening a new openssl.exe as Admin use the below command to verify the CSR file:
req -text -noout -verify -in anyname.csr
9) If everything is ok, provide this CSR to the CA to have it signed and receive a certificate back.
10) When you receive the cert from the CA, open the final cert file (that you received from the CA) in a notepad and make sure the order of the chain certs as below:
------BEGIN CERTIFICATE------
*Device cert*
------END CERTIFICATE------
------BEGIN CERTIFICATE------
*Root CA cert *
------END CERTIFICATE------
Or like this if you use cert with Intermediate CA cert:
------BEGIN CERTIFICATE------
*Device cert*
------END CERTIFICATE------
------BEGIN CERTIFICATE------
*Intermediate CA cert *
------END CERTIFICATE--------
------BEGIN CERTIFICATE------
*Root CA cert *
------END CERTIFICATE------
If this need to be changed then just reorder them as above (copy/paste) and save it in a new file as name.pem if it’s not already in this format.
now we need to combine the key (the private key file) with this cert using:
pkcs12 -export -in anyname-chain.pem -inkey anyname-key.pem -out anyname-chain-with-key.p12
Convert the cert from .p12 to .pem using:
pkcs12 -in anyname-chain-with-key.p12 -out WebAuth-Final.pem
Side Note: for users that wants to test that with Windows Server CA, Windows by default will generate the cert as .p7b to convert it to .pem use:
pkcs7 -print_certs -in certname.p7b -out certname.pem
and then combine the key (the private key file) with this cert using same above commands
11) once you have the final public cert, you need to download it to the WLC, you need to download and install certificate using CLI because of CSCvv72578 https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv72578
example:
transfer download mode tftp
transfer download datatype webauthcert
transfer download serverip x.x.x.x
transfer download path /
transfer download filename WebAuth-Final.pem
transfer download certpassword yourpassword
transfer download start
12) reboot the WLC
13) verify the new cert from SECURITY > Web Auth > Certificate
