First, some background to the question:
I have a Pulse Connect Secure VPN appliance in a multi-tenant environment, and I have been approached with the task of supporting certificate authentication (using smartcards specifically, but I don't believe that detail is relevant to the question). Each customer has their own certificate authority that issues client certificates to the end users.
Unfortunately, on the Pulse Connect Secure VPN appliance, it is only possible to configure trusted CA:s globally for the entire device. It's not possible to define this on the Authentication Server level or the User Realm level.
This is fine if you don't need to segment trust for different CA:s depending on what clients your serving, but it doesn't really support a multi-tenant environment very well.
The specific threat I'm trying to secure against is that if one customer's CA were to be compromised, they may issue VPN certificates with subjects belonging to a different customer. Therefore only the customer's own CA may be trusted to sign client certificates for their own organization, not for certificates granting access to other organizations.
After communicating with Pulse Secure's support department, they offered me a work-around, where I would configure multiple Authentication Realms (each of them connected to a specific sign-in policy and a specific sign-in URL, which is fine, because this is how we segment our tenants today).
Authentication would succeed no matter which customer's certificate was presented. When it came to the role mapping stage (authorization), a rule would be inserted at the top, which basically does a string-match on the "Issuer" field of the CA.
The rule would be something along the lines of this screenshot (this has not been tested to work exactly as written, the issuer attribute name might be wrong etc):
The rule would be inserted at the very top and would be the first rule to be matched. It would string-match the issuer name in the certificate, and if it does not match the expected issuer name, it would assign no roles, and by checking the Stop processing rules when this rule matches box, the role mapping stage would end with no roles assigned, and therefore the login attempt would fail due to no roles being assigned.
My reasoning/assumptions:
It is a given that the trusted CA:s added to the Pulse Connect Secure device are vetted to contain duplicate names only if those CA:s belong to the same organization. This means that the issuer name can be trusted to be unique to a specific trust domain.
It is also a given that assigning zero roles to a user that has passed authentication ensures that they will have no access to any protected system.
Any login attempts that go as far as role mapping have passed certificate validation and are therefore "valid", which would imply that the issuer field could be trusted to contain valid data. I'm assuming that a certificate issued by a valid certificate authority, but where the issuer name is something else than expected would fail certificate validation to begiin with before it even reached the role mapping stage.
Therefore string matching on the issuer field under these circumstances should be a secure way to enforce that only certificates issued by a specific CA are granted access.
Known risks:
During login, a list of valid CA:s is sent to the client for the purposes of filtering their view of valid login certificates in a process known as certificate negotiation. This can potentially leak a list of customers using that particular appliance, as well as cause a usability issue for users who are part of multiple organizations. In the face of not having an alternate way of solving this, I find that this risk is managable.
Scope limit:
I'd like to scope this question to only security of authentication and authorization, rather than broader questions of network design behind the VPN appliance.
My question:
So, after explaining all this background, I think my question in the subject line makes more sense:
Once a certificate has been validated, is it safe to string-match on the issuer field?
(Or is it going to bite me in the ass in some way I hadn't considered.)
