ISE 1.3 public wildcard cert

[trevorjenix]

Is it a good idea and common practice to just use public CA for wildcard certificate on each ISE node to avoid any certificate warnings on non-corporate devices? 

is it ok then to use it also for EAP-TLS authentication? Clients will still have internal CA certs.

Or should we have a separate internal wildcard cert just for EAP-TLS. In this case, will ISE 1.3 allow me to have to wildcard certs with the same SAN (*.domain.com), one is public, the other is internal. The public one would apply to Web portals, and internal one would apply to EAP-TLS/

[nspasov]

Hi Trevor-

The use of Wildcard cert is perfectly acceptable for the guest portals. As you said, this will ensure that guest users don't get the certificate trust error. 

However, for the EAP side of the house, you will need to get a non-wildcard certificate. Many supplicants (including Windows) will NOT accept a wildcard certificate when building an EAP tunnel.

I hope this helps!

Thank you for rating helpful posts! 

[trevorjenix]

Hi Neno,

have a quick follow up on your comment about using wildcard certs for EAP. Is the issue with the cert being the wildcard or begin the SAN cert? I was wondering if it's ok to create a single SAN cert with all ISE PSN names in it (without wildcard) for EAP authentication?

I also noticed that in ISE documentation and even on the page where you create CSR, they clearly reference EAP for Wildcard certificates. Are you sure these are not supported for ISE? Maybe it's only when you use wildcard in the CN=? It seems that if you use wildcard in the SAN field only, that i should support it?

Thanks!

[nspasov]

Hi Trevor-

For your first question:

- Yes, you can definitely use a SAN certificate to do this. I have done it many times before in large deployments in order to avoid the manual labor of creating a certificate for every PSN node. So I would use something like "Open SSL" and generate a CSR with:

- CN = ise.company.com

- SAN = psn1.company.com ---> FQDN of the PSN node

- SAN = psn2.company.com ---> FQDN of the PSN node

- Repeat for all PSN nodes in the deployment

For your second question:

- Yes, you can use a Wildcard cert but only where the wildcard statement ( *.company.com) is in the SAN field. If you have wildcard string in the subject/CN field then the Microsoft supplicants would reject it:

Wildcard Certificate Compatibility

Wildcard certificates are usually created with the wildcard listed as the Common Name (CN) of the Certificate Subject, such as the example in Figure 8-3. Cisco ISE release 1.2 supports this type of construction. However, not all endpoint supplicants support the wildcard character in the Certificate Subject.

All Microsoft native supplicants tested (including Windows Mobile) do not support wildcard character in the Certificate Subject.

You can use another supplicant, such as Cisco AnyConnect Network Access Manager (NAM) that might allow the use of wildcard character in the Subject field.

You can also use special wildcard certificates such as DigiCert's Wildcard Plus that is designed to work with incompatible devices by including specific subdomains in the Subject Alternative Name of the certificate.

Although the Microsoft supplicant limitation appears to be a deterrent to using wildcard certificates, there are alternative ways to create the wildcard certificate that allow it to work with all devices tested for secure access, including the Microsoft native supplicants.

To do this, instead of using the wildcard character in the Subject, you must use the wildcard character in the Subject Alterative Name (SAN) field instead. The SAN field maintains an extension designed for checking the domain name (DNS name). See RFCs 6125 and 2128 for more information.

I hope this helps!

Thank you for rating helpful posts! 

[trevorjenix]

Aha! Yes, I did know about the restriction, that you need to put wildcard into the SAN. So, let me get this straight. I can potentially use a *single* public wildcard cert for all needs in ISE (admin, EAP, portals) and it should all work. The cert's CN= will be something arbitrary like ise.ise.domain.com, and SAN will contain DNS1 as ise.ise.domain.com, and DNS2 as *.ise.domain.com. The domain domain.com happens to be public and private, so public CA won't have a problem issuing the cert. And I don't believe there are any problems for let's say EAP-TLS to use a public cert on the server side, and internal CA (SCEP) certs on the client side as long as internal CA's trust root certs are loaded into ISE.

And by the way, is it really necessary to use openssl? ISE 1.3 allows the creation of CSR with this setup where wildcard is in the SAN. 

What do you think of this?

[nspasov]

Sorry for the delay Trevor but work has been keeping me very busy!

Question #1: Yes, you can use that setup. As long as the CN does NOT have a wildcard value then supplicants should not have a problem with it. 

Question #2: Yes, as long as you are not using a private domain then public CAs should not have a problem issuing certs to you

Question #3: 

And I don't believe there are any problems for let's say EAP-TLS to use a public cert on the server side, and internal CA (SCEP) certs on the client side as long as internal CA's trust root certs are loaded into ISE

I am not entirely sure what the question is here. EAP-TLS requires both a client and a server side certificate. Thus, if you are going to use a public CA for your server certificate then the client side certificates would also have to be issued by that same CA. If you have an internal CA then you would use that for issuing certificates to your domain machines and users. You would also use that CA for SCEP integration for NDES. The public certificate would then be used for HTTPs based requests. It can also be used for PEAP based authentications where only a server side certificate is needed for the establishment of the EAP tunnel. 

Question #4: Yes, you can use ISE to generate the CSRs. I am a bit old school and use open ssl. I have been working with ISE since 1.0 and the CSR "tool" inside ISE was horrible :)

Thank you for rating helpful posts!

[trevorjenix]

Hi Neno, about your statement:

"EAP-TLS requires both a client and a server side certificate. Thus, if you are going to use a public CA for your server certificate then the client side certificates would also have to be issued by that same CA."

Are you sure about this? Is it not possible to have EAP-TLS client and server certs signed by different CAs?

[ajc · Accepted solution]

Hi Trevor,

If I am not wrong, you could have EAP-TLS client and server certs signed by different CA, but ONLY IF, in your ISE Primary PAN Node --- > Certificate Store, you have a valid/signed certificate from the same CA that signed the cert presented by the client.

EAP-TLS is a 2 ways certificate authentication so if the certificate presented by ISE was signed let's say by Entrust and Entrust is part of the client (win 7 laptop) Trusted Root Certification Authorities or Intermediate Certification Authorities the ISE certificate is valid for the client. Similarly, the certificate presented by the client signed by Verisign is checked by ISE against its Certificate Store and if ISE has an entry for Verisign Certificates, then the process is completed and the authentication is completed.

Sometimes for example Chromebook devices (client devices) do not have the CA Certificates preloaded so when ISE presents it EAP-TLS certificate you get a warning and you decide or not to accept the certificate as valid. However the opposite is mandatory, I mean Chromebook must present a valid signed certificate so ISE can check it against its certificate store in order to complete the process and allow access.

Hoping this answer your question.

[nspasov]

You can take a look at the EAP-TLS deployment guide:

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_white_paper09186a008009256b.shtml

The guide has a section that talks about this:

To support EAP-TLS, the AAA server (for example, Cisco Secure ACS) must have a certificate. Either a public certification authority or a private certification authority can be used to issue the AAA server certificate. The AAA server will trust a client certificate that was issued from the same root certification authority that issued its certificate.

Now, with that being said, I have never tried using different CAs for issuing the client and the server certs so I am not saying that it would not work. I am just going by what I have read :)

Thank you for rating helpful posts!

[nspasov · Accepted solution]

Hi Trevor-

The use of Wildcard cert is perfectly acceptable for the guest portals. As you said, this will ensure that guest users don't get the certificate trust error. 

However, for the EAP side of the house, you will need to get a non-wildcard certificate. Many supplicants (including Windows) will NOT accept a wildcard certificate when building an EAP tunnel.

I hope this helps!

Thank you for rating helpful posts! 

[trevorjenix]

Appreciate this, it clears it up well.