Certificate requirement for guest posture

[jdal]

Hi,

My customer is trying to do posture for guest users. It's a big corporation with different entities.

They have decided to dedicate specific PSN to each entities.

For example, the FQDN of their PSN would look like this:

psn1.subCompanyA.com

psn2.subCompanyA.com

psn1.subCompanyB.com

psn2.subCompanyB.com

I would like to understand exactly what are the requirements regarding certificates.

Ideally, we would be in a multi-interface scenario...

If I understand correctly, we would need a public certificate for the provisioning portal (tcp/8443) but then for the SWISS protocol (TCP/8905), we would use the admin certificate. That means this certificate should also be signed by a public authority ?? Since logically it would be bound to Ge0, we would also need to add the FQDN/IP address of the Gi1 as a SAN?

The customer currently have around 10 entities with 2 PSN each. That means, they should request around 20 public certificates (or a single one with 20 SAN).

Luckily, it looks like we can tweak ISE not to return the IP address of the PSN but instead a FQDN (defined with the ip host command in CLI).

If we now create specific FQDN such as:

psn1.subCompanyA.posture.ise.Maincompany.com

psn2.subCompanyA.posture.ise.Maincompany.com

psn1.subCompanyB.posture.ise.Maincompany.com

psn2.subCompanyB.posture.ise.Maincompany.com

We should be able to use a single wildcard certificate *.posture.ise.Maincompany.com for the provisioning portal.

We should also be able to use a wildcard for the admin certificate: *ise.Maincompany.com

Could you confirm this should work and I haven't missed anything?

One more thing, thanks to CSCut30037, it looks like we would finally get rid of the requirement on the admin certificate. This ddts is currently in the Assigned state. In which release can we expect to see that fixed?

Thanks,

JF

[Timothy Abbott]

JF,

I think you are on the right path with wildcard certificates.  That would allow for the use across multiple portals and for posture scenarios.  As for the defect, we can't state when a fix will become available since many factors attribute to when it will become available.  If it is critical the customer has a fix, you could always open a TAC case and have it escalated so that an hot fix could be issued.

Regards,

-Tim

[Jason Kunst]

Here is some information on that

https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/admin_guide/b_ise_admin_guide_23/b_ise_admin_guide_23_chapter_0111.html#concept_8ECCCAF1252E40DDB9A786C0AC7BC3B2

[Jason Kunst]

Can you explain why you are posturing guest? Are you going to try and have them install anyconnect?

[jdal]

Sorry for the confusion, we are not really in the guest workflow mode but more in RA VPN access... the customer is providing access to a bunch of external people (like myself) through VPN (indeed ASA with Anyconnect).

However since most of these people don't have the corporate root certificate, we need to rely on public CA.

[Craig Hyps · Accepted solution]

I don't think using wildcards with different domain levels will work since *.company.com is not the same as *.subdomain.company.com.  We addressed the issue for BYOD in ISE 2.2 (ref CSCut36534 - ISE 1.3 in BYOD provisions Admin cert instead of BYOD portal Cert).

For posture I am checking if still issue.  I do see CSCut30037 in Assigned state.  There are different phases of redirection.  For initial discovery where packets sent on http/80, it makes sense that the admin portal cert would be used since also listening on that port.  Once redirected on 8443, then may be option to select different cert like client provisioning portal cert for selected interface.  Since still assigned, I suspect still not finalized. 

[hslai]

ISE 2.2 Posture and Client Provisioning add a new parameter "Call Home List", which can be a comma-separated list of IPs or FQDNs with an optional port number.

For example, we may specify it a value of the all PSNs with ISE Client Provisioning Portal (CPP) port number:

psn1.subCompanyA.posture.ise.Maincompany.com:8443,psn2.subCompanyA.posture.ise.Maincompany.com:8443,psn1.subCompanyB.posture.ise.Maincompany.com:8443,psn2.subCompanyB.posture.ise.Maincompany.com:8443

This way, the AnyConnect agents will use the CPP port and the certificate designated for the CPP for posture communications.

Some well-known CAs do not issue wild-card certificates. Instead, many of them provide Subject Alternate Name (SAN) certificates (aka Unified Communication (UCC) certificates) so that customers may put many SAN entries on the same certificates.