[openssl-users] SSL_CTX_set_cert_verify_callback and certificate access

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
> Sent: Thursday, January 10, 2019 11:15

> On 1/9/2019 6:54 PM, Corey Minyard wrote:
>> 2. Set the userid in the certificate and use client authentication to
>>   authenticate the user logging in.  Set the username in the CN field
>>   of the certificate so it can't be changed, extract that and set the
>>   CA before verification.  This is what I'm currently trying to do,
>>   and I keep running into roadblocks.

> Why do you think you need to set the CA?

Agreed. That's an odd requirement.

> Then you look at their subject name to derive the user ID (probably from its CN).

That's one logical option, but some systems (e.g. IBM zOS) instead maintain a database mapping client certificates to system user IDs. That has the advantage of not imposing any particular requirement on the client certificate's subject name format, with the disadvantage of additional administration. (For HTTPS, there's a provision for "automatic registration" where an unrecognized but valid and trusted client certificate will trigger HTTP Basic Authentication, and if those credentials are verified by the OS, the certificate is added to the database.) The database may index certificates by subject DN (for ease of administration, e.g. when certificates are renewed) or by fingerprint (as a defense against impersonation if a CA is compromised).

> If you want to be really paranoid - if you believe that Verisign can vouch for John
> and Comodo can vouch for Sam, but not vice versa, factor the issuer name into the process.

Right. For the original "set the CA" plan to work, you would need to already have some association between client certificates and CAs, so you can simply check that a validated client certificate was issued by the expected CA.

But again this would be an unusual requirement; and even if it exists, the contemporary standard mechanism for guarding against rogue or compromised CAs is Certificate Transparency. Checking CT logs seems like overkill in this case, and it would arguably be more useful to implement revocation checks and other defenses first; but if restricting certificates by issuer is important for some reason, CT might be a better approach than inventing your own mechanism.

Regarding Corey's original note: SSL/TLS does not have a "username" concept because it would be redundant or inconsistent. A certificate is a peer identifier; it takes the place of a username.

--
Michael Wojcik
Distinguished Engineer, Micro Focus