How can I know the FQDN & names for installing a Public Digital Certificate in ISE?

[Rodrigo Moreno]

We're implementing a project with Cisco ISE; but the Guest Portal appears to users as an "untrusted site". For solving that, a Public Digital Certificate must be installed in Cisco ISE, for it to send it to the users who enter the Guest Web Portal.

Now....for selling me the certificate, VERISIGN needs to know the ISE parameters for the certificate, such as FQDN, names, subnames, etc....how can  know these parameters from ISE?

Thaks a lot!!

[aman.diwakar · Accepted solution]

This is not an easy question to answer there are a ton of variables to include

Local web Auth or Central Web Auth

In LWA, the WLC is the "middle man" for the request from the client to the PSN (Guest Server Nodes), the WLC takes the webauth request and looks at webauth then the redirect URL that you've put into the WLC

If the webauth redirect URL is  https://ise01.mycompany.com:8443/guestportal/login.action, the WLC does a redirect but the virtual IP comes into play 1.1.1.1, which also has to be trusted or the redirect complains, so you may have to get public certs for the fqdn of 1.1.1.1 and the guest server. You can create a CSR using openssl or you can just go into ISE and create a CSR, but you can only put in CN=ise01.mycompany.com and nothing else, as long as you have a single PSN thats fine, but if you have multiple PSNs, you will need to modify your CSR so that you have to use openssl to create the CSR using an openssl.cnf file, then with openssl, you do the following:

openssl req -new -nodes -out omf-01-ise04.csr -config openssl.cnf

You have to do it the way I've noted above regardless of CWA or LWA, if you have more than one PSN, you have to point to a VIP FQDN and then configure your DNS to answer for those hostnames. With LWA, you dont get the WLC Virtual IP 1.1.1.1 involved, so you dont have to worry about getting a certificate for that, its a much cleaner setup, but you still need to do everything else. Then you have to make sure that your guest users have the ability to reach the guest portal and be able to resolve the DNS given the dns server that they have been configured with.

Contents of openssl.cnf file:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
default_bits = 2048

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = US
localityName = Locality Name (eg, city)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 40

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth,serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1   = guest.mycompany.com
DNS.2    = guest.mycompany.com
DNS.3 = ise01.mycompany.com