Portals with wildcard certificates do not work with Android 10+

[Arne Bier]

Hello

It's been a while since I have had to deal with an ISE Portal issue. Today was a struggle to get Android devices to not complain when trying to connect to a simple ISE Hotspot Portal. It was surprising to me that Windows and Apple iOS devices had no issues at all. Cisco 9800-CL controller running 16.12 release and ISE 2.7 patch 3. Simple Hotspot Portal with two PSNs. The Authorization Profile was returned to the client in the form of portal1.company.domain.com or portal2.company.domain.com (depending on which PSN serviced the MAB request) - and the Portal certificate was assigned to a Portal Tag using a wildcard certificate: Subject = *.company.domain.com, SAN = DNS:*.company.domain.com and DNS:company.domain.com - this certificate is used in many other web-based systems without any complaints.

The solution to our Portal problem was to purchase a new certificate that did not contain any wildcards at all. The new cert contained the FQDN of the ISE portal in the Subject Common Name, as well as in the SAN.

The other weird thing was with Oppo phones (also Android based) - these devices plain refused to authenticate to the SSID until I enabled Fast Transition (802.11r) to 'Enabled' (I had it disabled to begin with). Normally it's the other way around - fancy features usually prevent devices from connecting.

Maybe this helps someone else who might run into this. Android is going through the teething pains that Apple went through some years ago. And it's enforcing HSTS in a big way.

But the lesson I learned is to request a Portal certificate that contains the exact FQDN of every portal you need - and NO wildcards.

[Damien Miller]

Having a wildcard in the CN has always caused me issues with Microsoft machines, so this does not surprise me. Every customer I've used a wildcard cert with, we did so by getting the wildcard entry in as a SAN. 

The last year has brought so many certificate changes on the OS side too, it's hard to keep track of it all. Apple no longer accepts a cert with a valid period longer than 397 days if issued after Sept 1 2020. This was semi decently communicated, but it also applied to all of the large vendors. 

Android also dropped support for SHA-1 certs in a single liner in the release notes. Full time job just keeping up. 

[athan1234]

Hi @Arne Bier . I would like to revisit this concept. Because i got the same problem with the wildcard certificate

I suggested my customer that creating a unique FQDN and Sam as your diagnosis for soved the problem

My customer asks me if I can pass to him the precise FQDN that he has to pass for Gernerete and SAM, but I'm not sure about them.

It is accurate to inform my client that the online portal is called FQDN.

xxxx.yyyyyy.com (The precise name of the portal )

And what is the proper name for the SANM that I must enter?

Best regards

[Arne Bier]

Let's use an example.  Imagine your organisation owns a DNS domain called  acme.com (that is, they can prove the ownership of this domain to obtain a public signed cert) - and that they want to host two ISE portals (one per PSN, if there is a High Availability setup) - the portal FQDNs (Fully Qualified Domain Names) below are the examples. Of course, the DNS must resolve each FQDN to the respective ISE PSN node

ISE PSN 1:  portal1.acme.com

ISE PSN 2: portal2.acme.com

I would plan purchase one public certificate that contains multiple SAN (Subject Alternative Names). You create a CSR (Cert Signing Request) in ISE, and fill in the details

Subject:  portal.acme.com
Organization: Your Org
Country: Your country Code
SAN: DNS: portal1.acme.com
SAN: DNS: portal2.acme.com

Notice that the Subject does not match either of the SAN entries. It doesn't matter. Browser will ignore to check the Subject - and will check the SAN entries only.

Submit the CSR to the public CA. Once you get the cert from the CA, you bind the cert to the ISE CSR. And you will assign the Portal Tag to that cert according to the Portal Tag that is configured to that ISE Portal. 

When creating the ISE CSR, I select only one of the nodes (e.g. PSN1) during CSR creation. That means it puts the CSR details on PSN1 only.  Once you have bound that cert to PSN1, you can export the cert (with private key) and import that cert into PSN2.  I don't recall if there is a smarter way of doing this. But it works for me.  The main point is that the portal system cert must be installed on each PSN that is hosting the portal.

And of course, depending on your public CA you have chosen, install their CA Root chain in the ISE Trusted Certs (Root, Issuing, etc.) - do that before you bind the portal cert!

[athan1234]

Hello, @Arne Bier  appreciate your response and explanation.

I returned to the office today carrying this theme after being away.

I must ask you to confirm that it is accurate.

Currently, bienvenido.solocore.com:8443 is the portal page.

There is just one node.

The FQDN of the node is:

TLPC02.solocore.com

I take your post to mean that the idea is to generate CSR.

It is correct?

[Arne Bier]

Hello there,

Your example shows a self-signed certificate request. We don't want to sign it ourselves - we need a CSR for a Portal that we can submit to a public CA to get signed.

Then select your node (check box)

In the CSR details, overwrite the Subject with the FQDN of the portal. OU, Country etc can also be filled as you wish. RSA 2048 and SHA256 is the common standard used by most CAs. Submit that to the CA and then bind the certificate they give you to this CSR. Ensure also that your ISE Guest Portal config has this same Portal Tag defined up above. 

[athan1234]

Thank you @Arne Bier   . 

I followed your instructions. In order for me to bind the certificate, I need the CA to sign it.

so much obliged

[athan1234]

Hi @Arne Bier  

I am binding the certificate today, yet I received this "stale" state.

I recently joined the Cert format. I'm not sure if I really need to enter the certificate trust host as well.

I was reading in other post about state stale :

Stale System and Trusted Certificates

Stale certificates are certificates that don’t belong to any node in the deployment. These redundant certificates might accumulate in large numbers in the System and Trusted Certificate stores, leading to insufficient memory and latency issues. From with Cisco ISE Release 3.1, such redundant certificates carry a Stale Certificate status, enabling you to review and delete them.

I cant understand . Maybe the error was for i would have to include the ise node of the name ? 

NODEISE.bienvenido.solocore.com

[Arne Bier]

Don't worry about the "Stale" certificate status. In my opinion, that new ISE "feature" is broken and just causes more confusion than required. I have also noticed it since the newer versions of ISE, and it only appears (for me) when I have portal certificates installed. I think ISE is not clever enough to realise that the Subject (and or SAN) contains FQDNs that relate to the Portal linked by the ISE Portal Tag. Because the FQDN that we return to the wireless clients (in the Authorization Profiles) in the form of a URL redirection, would require some fairly complex logic in ISE to figure out. I wish this feature didn't exist in ISE -it never used to be there. 

You'll be fine as long as your certificate contains the correct FQDN(s) for all your ISE Portals to which the certificate portal tag is bound. At a minimum, I always have two PSNs, and each PSN has its own FQDN (e.g. guest1.company.com and guest2.company.com, for PSN1 and PSN2 respectively).  Depending on the cost of the cert, either one cert for both nodes (SAN contains guest1 and guest2) or one cert per node. 

[athan1234]

thank you for your support @Arne Bier 

I talked to my customer, and everything is operational now that the guest portal's FQDN certificate has been issued.

So, many thanks