Cert-manager: Option to specify x509 extensions on certificates

[oninoshiko]

I have the ingress server configured to do OCSP stapling. I would like to enforce this on the cert, to make it harder on someone who has obtained the key to a revoked cert.

I would like a way to enable tlsfeature=status_request

I spent some time looking around the manual, to see if there was anything about enabling this feature, but couldn't find anything. Hopefully I'm just overlooking it.

[munnerz]

What other values can tlsfeature be set to, and how do you think this should be exposed in the Certificate resource?

I'm not too familiar with OCSP configuration so it'd be great if you could provide a little extra context around how features can be configured 😄

[oninoshiko]

I would expect an optional field in the Certificate resource which accepts an arbitrary string. In openssl, this would just be put into the v3_req section of the config used to generate the CSR. Openssl 1.1.0 and later can use the easier to read "tlsfeature" notation tlsfeature = status_request, early versions have to use the OID with the field listed as ASN.1 DER encoded data (ie: 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05)

The relevant RFC is RFC 7633. According to that,

Currently, the only TLS feature extensions that are relevant to the revocation status of credentials are the Certificate Status Request extension (status_request) and the Multiple Certificate Status Extension (status_request_v2). These extensions are used to support in-band exchange of Online Certificate Status Protocol (OCSP) tokens, otherwise known as OCSP stapling. These extensions are described in [RFC6066] and [RFC6961].

I don't think I've actually seen status_request_v2 in the wild yet, but there's no reason not to allow it.

[oninoshiko]

If it's unclear, the reason I'm requesting this is security related:

If a cert has to be revoked, that revocation is only significant if the client checks for revocation. Normally that's done by asking the CA's OCSP server (CRLs have fallen out of favor, for good reasons). In order to avoid the overhead of the additional request, OCSP stapling allows the server using the cert to request a signed copy of the cert's revocation status, and send it with the cert.

While stapling alone helps performance, the client doesn't know if it should expect it or not. Worse, because CA's OCSP servers have proven unreliable, many clients treat any cert that they cannot get OSCP data on as unrevoked. This presents an obvious attack vector with a revoked cert of not stapling and DOSing the OSCP servers.

Must staple turns that on it's head. The cert itself now tells the client that the server MUST staple the revokation information. If that doesn't happen, the client should treat the cert as invalid.

[munnerz]

/cc @DanielMorsing

On Thu, 7 Feb 2019 at 16:37, A Hettinger [e-mail] wrote:

I would expect an optional field in the Certificate resource which accepts
an arbitrary string. In openssl, this would just be put into the v3_req
section of the config used to generate the CSR. Openssl 1.1.0 and later can
use the easier to read "tlsfeature" notation tlsfeature = status_request,
early versions have to use the OID with the field listed as ASN.1 DER
encoded data (ie: 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05)

The relevant RFC is RFC 7633 https://tools.ietf.org/html/rfc7633.
According to that,

Currently, the only TLS feature extensions that are relevant to the
revocation status of credentials are the Certificate Status Request
extension (status_request) and the Multiple Certificate Status Extension
(status_request_v2). These extensions are used to support in-band exchange
of Online Certificate Status Protocol (OCSP) tokens, otherwise known as
OCSP stapling. These extensions are described in [RFC6066] and [RFC6961].

I don't think I've actually seen status_request_v2 in the wild yet, but
there's no reason not to allow it.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/issues/1282#issuecomment-461502352,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbP7gmLYRBGp3Z-SMy9CudIyZh7JJHks5vLFZdgaJpZM4aZrmb
.

[DanielMorsing]

We need to figure out a way to specify x.509 extensions, which could be a bit of a hassle, since there isn't a universal way of textually representing them.

As for OCSP must-staple, it is sporadically implemented by clients. Notably, chromium does not support it, so the benefit of implementing it as a one-off is fairly low. Until we figure out how to specify x.509 extensions, I would recommend you set NotAfter to sometime soon, like 14 days

[oninoshiko]

Thanks for the feedback.

Would it at least be possible to allow arbitrary OIDs with ASN.1 DER encoded values? That should automatically allow all present and future extensions to be handled, even if in a not-user-friendly way.

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[oninoshiko]

/remove-lifecycle stale

While this isn't a priority, it should still be on the agenda.

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[oninoshiko]

/remove-lifecycle stale

[JoshVanL]

Hi @oninoshiko
Do you have any suggestions about how to go about implementing this going forward?
Particularly, how will this be represented inside the API?

[pieterlange]

This should probably get some attention before cutting v1/stable API objects :)

Other usecase: client certificates (also a TLS extension param)

[munnerz]

Key usages are already supported as of v0.11. This ticket is specifically for extensions, which is a whole other realm of x509 complexity :)

Also, I’d guess that we can implement this post-v1 as any addition here should be backward compatible just fine.

[pieterlange]

Hmm.. forgive my confusion (not a x509 dev ;-)), i didn't notice this new functionality yet!

Will test this out soon and contribute a docs snippet for issuing client certs (confused extended key usage with extensions)
https://github.com/jetstack/cert-manager/blob/master/pkg/util/pki/csr.go#L150

[oninoshiko]

Sorry for not replying sooner:

@JoshVanL It depends, if we want to be able to add the specific named extensions that a list containing the options you want to turn on, maybe named "extensions" under the Certificate spec. Something like:

spec:
  <other stuff here>
  tlsextention:
  - status_request

It could just as easily be implemented as a generic list of OIDs to add (also under the certificate spec). Then I could enter the more generic (but less userfriendly)

spec:
   <other suff here>
   OID:
   - 1.3.6.1.5.5.7.1.24: DER:30:03:02:01:05

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[Morriz]

Hi, it seems certbot can be started with --must-staple. Is there no option as such for cert-manager? Are there any known workarounds for that? I think it could mean the difference between getting an A and an A+ on our SSL review.