[openssl-users] SSL_CTX_set_cert_verify_callback and certificate access

[Jakob Bohm]

On 10/01/2019 18:00, Michael Wojcik wrote:
>> 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.
CT does nothing of the sort, it just provides a means to ensure all
certificates are potentially subject to 3rd party audits.

And CT cannot be legally used for user certificates anyway because
CT publishes unredacted certificate content to the world.

One really should be careful with security ideas from a company whose
main source of income is to spy on the world population for profit.

> 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.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded