Client-Certificate blocking without conrolling the issuing CA

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Client-Certificate blocking without conrolling the issuing CA

Vincent Truchsess - rockenstein AG
Hi,

I am well aware that the usecase I'm going to describe is not how pki is intended to be implemented but unfortunally, the organizational architecture of ths particular application is out of my teach.

We are operating an application that strongly relies on client certificates as the outer authentication layer. Those certificates are issued as 'general purpose' client-certs by a globally trusted root-ca and are being validated on dedicated hardware limiting the level of flexibility in the matters of access control.
The organization legally responsible for the application maintains a blocklist of certificate serials they consider to be invalidated. Also, this organization does not bother to get those certificates revoked by their CA so using OCSP or CRLs against the CAs services has no effect on denying access to invalid users.

The hardware performing the certificate-validation allows for locally stored CRLs. Our intention was to generate those ourselves using a selfsigned CA. As far as I went, it seems that openssl only allows for revocations of certificates signed by the local CA.

Doing this in software (e.g. inside the application) wouldn't be a problem but the amount of parallel connections require this to be handled by dedicated hardware which is limited to CRLs and OCSP.

Is there any way we simply have overlooked that allows us to generate selfsigned CRLs for certificates issued by another CA using openssl?

Thanks you for your time,
Vincent TruchseƟ.


PS: Implementing a 'scriptable' OCSP-responder would be an option that is planned but will take too long to hotfix the current issue.
Reply | Threaded
Open this post in threaded view
|

RE: Client-Certificate blocking without conrolling the issuing CA

Michael Wojcik
> From: openssl-users <[hidden email]> On Behalf Of Vincent
> Truchsess - rockenstein AG
> Sent: Friday, 4 December, 2020 04:27
>
> The organization legally responsible for the application maintains a
> blocklist of certificate serials they consider to be invalidated. Also, this
> organization does not bother to get those certificates revoked by their CA so
> using OCSP or CRLs against the CAs services has no effect on denying access
> to invalid users.
>
> The hardware performing the certificate-validation allows for locally stored
> CRLs. Our intention was to generate those ourselves using a selfsigned CA. As
> far as I went, it seems that openssl only allows for revocations of
> certificates signed by the local CA.

I assume you mean "certificates signed by the issuing CA". The CRL has to be generated by the CA that issued the certificates.

It seems to me that the simplest solution would be to have the application add a certificate validation callback that checks the serial number against this not-really-a-CRL list of forbidden client certificates. That's the sort of thing certificate validation callbacks are for: implementing additional restrictions (or removing existing ones) on which certificates will be accepted.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

AW: Client-Certificate blocking without conrolling the issuing CA

Vincent Truchsess - rockenstein AG
That would be the the ideal solution. The problem is that the customer's security-policy demands dedicated hardware performing IDS/IPS functionality at the point of TLS-termination. The devices at hand do not provide the functionality to call a user-defined external service for certificate validation apart from OCSP.

The future workaround will be a mockup OCSP-responder but that solution will need some time for implementation. our current focus lies on a rather quick than perfect solution that buys some time to ship something more solid.
________________________________________
Von: openssl-users <[hidden email]> im Auftrag von Michael Wojcik <[hidden email]>
Gesendet: Freitag, 4. Dezember 2020 15:07:02
An: [hidden email]
Betreff: RE: Client-Certificate blocking without conrolling the issuing CA

> From: openssl-users <[hidden email]> On Behalf Of Vincent
> Truchsess - rockenstein AG
> Sent: Friday, 4 December, 2020 04:27
>
> The organization legally responsible for the application maintains a
> blocklist of certificate serials they consider to be invalidated. Also, this
> organization does not bother to get those certificates revoked by their CA so
> using OCSP or CRLs against the CAs services has no effect on denying access
> to invalid users.
>
> The hardware performing the certificate-validation allows for locally stored
> CRLs. Our intention was to generate those ourselves using a selfsigned CA. As
> far as I went, it seems that openssl only allows for revocations of
> certificates signed by the local CA.

I assume you mean "certificates signed by the issuing CA". The CRL has to be generated by the CA that issued the certificates.

It seems to me that the simplest solution would be to have the application add a certificate validation callback that checks the serial number against this not-really-a-CRL list of forbidden client certificates. That's the sort of thing certificate validation callbacks are for: implementing additional restrictions (or removing existing ones) on which certificates will be accepted.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

RE: Client-Certificate blocking without conrolling the issuing CA

Michael Wojcik
> From: Vincent Truchsess - rockenstein AG <[hidden email]>
> Sent: Friday, 4 December, 2020 08:59
>
> That would be the the ideal solution. The problem is that the customer's
> security-policy demands dedicated hardware performing IDS/IPS functionality
> at the point of TLS-termination. The devices at hand do not provide the
> functionality to call a user-defined external service for certificate
> validation apart from OCSP.
>
> The future workaround will be a mockup OCSP-responder but that solution will
> need some time for implementation. our current focus lies on a rather quick
> than perfect solution that buys some time to ship something more solid.

Ah, I see. Thanks for the clarification.

I don't offhand see a quick workaround for your situation. I'm not sure what would happen if you cross-signed all the client certificates with a CA under your control, and then generated a CRL for the ones you want to exclude. Or actually you could just cross-sign only the ones you want to allow, and made your CA the only trust root for the TLS termination systems; that would work. But I'm guessing modifying every client certificate is not a feasible solution for you either.

If it is, cross-signing with a CA under your control and trusting only that CA is probably the approach I'd go for. That's a legitimate approach under PKIX. It could even be mostly automated, except the end users would have to install updated user certificates, which is probably a deal-breaker.

--
Michael Wojcik