Add support for CRL when using TLS Auth

[jniebuhr]

Is this a request for help?: No

What keywords did you search in NGINX Ingress controller issues before filing this one?: CRL (also looked for the nginx directive in the code, wasn't there)

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

NGINX Ingress controller version: Latest

What you expected to happen: When putting a ca.crl file in the secret that contains the ca.crt file, I'd expect the controller to also copy that file to the filesystem and put the ssl_crl directive into the nginx config.

[rikatz]

@jniebuhr Thanks for your report. Actually NGINX Ingress supports OCSP stappling.

The CRL supports needs to be improved, but it's a gap in major Open Source HTTP / Proxy servers. They relies in a file being downloaded times to times to the server, and then the server needs to be reloaded.

As this is an easy to implement solution in small environments, on some environments that have hundreds of trustable CAs this tends to be impossible, as you have to know each of the CAs and their CRL locations.

A desired behaviour for those servers (not ingress, itself) is to download those files from the specified CRL inside the CA, as Microsoft IIS server does. So when you use a Certification Authority, it does download the CRL (and caches it) before, not relying if you do have or not them phisically in your server.

A recent PR that happened here downloads the whole chain of a Certificate (as happens here ) but this needs also some kind of caution, as this might impact in your server performance (we could also make some kind of timer or anything else that triggers this to CRL, but don't know if this is something easy to implement).

Anyway, your concern of using CRL is right. Doing as you specified in What you expect to happen isn't anything pretty hard, but you'll have to keep your CRL secret synced as CRLs tends to change a lot of times per day / week :)

Hope I could explain to you the bigger problem here, and if you have any idea in how to solve this, I'm here to help.

My bet is a NGINX module that changes the behaviour and makes this pretty much the same behaviour as IIS Servers, but I'm not close to be a C developer :)

[jniebuhr]

I have a Self signed authority that I create my client certificates from. When revoking a client certificate (like when an employee leaves the company), OpenSSL will make a CRL for me. I would like to put that into the same secret my CA is in for client with. That should be pretty easy but sadly I’m not really fluent in Go.

[rikatz]

@jniebuhr Isn't this the case to enable OCSP in your OpenSSL CA, emit a new CA (don't know what's the level of 'production' your CA is) and use OCSP stapling in NGINX? :)

Anyway I'll think in something here, as I also do need some kind of CRL downloading (as made with the full chain), but I'm without much time to do this by now :(

[jniebuhr]

Just read about OCSP. Well we don't have any OCSP server yet. Right now, the CA is only available in the secret. I guess it would make the setup much easier if one could just put the CRL in the secret with the CA cert and kick the ingress pods.

[zeeZ]

To chime in my opinion, I think this shouldn't be overcomplicated and, at least for me, the expected behaviour would be just as it works in nginx configuration: You point it to a static file and every time you make a change to this file nginx needs to be reloaded for it to take effect.

This should simply map to the server's configuration and does not have to do any magic.

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ghost]

/remove-lifecycle stale

I support what @zeeZ said. I would like to point to a resource (secret, if that is what everyone wants) and every time it is touched, the ingress reloads.

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[bputt]

/remove-lifecycle stale

Is there anyway this could get added to the baseline? I agree that adding the file as a secret is sufficient and an auto reload once it changes would be perfect.

[rikatz]

Hi,

I'll take a look into the implementation of this (too much stuff have changed since last time I've been here) and see if it's possible to make as the follow:

• Fetch/sync the secrets for the CA Authentication from the very same CA Secret used (here)[https://github.com/kubernetes/ingress-nginx/blob/master/internal/ingress/annotations/authtls/main.go#L91] but probably from a field other than 'ca.crt' (probably ca.crl)

• If the value if not null and it's validated as a working CRL, will do the rest (create the CRL file, point the vhost into this file)

Don't know how much time will take, and if this does have some impact into the work being done by @aledbf and @ElvinEfendi to remove the 'reloads' from ingress, but let's see it later.

If someone did understood what's the way here and want's to code this feature before me, just let me know and I'll help reviewing and so.

Tks!

[zeeZ]

Here's a dirty hack that works right now:

1. Use a custom template where you duplicate the ssl_client_certificate line that points to the CA file and change it to ssl_crl
2. Append the CRL to the ca.crt in your auth-tls-secret

This may or may not be the source for "cert already in hash table error" alerts, but hey.

[stanislavvv]

I can't use OCSP with self-signed CA working for several years in production...

How about add new line ssl_ca_crl (not use if empty) and let's it update by external scripts?
It will be added to nginx configuration
It can be a good start.

Next point - something like ssl_ca_crl_update_url (something like "https://ca.company.tld/crl.pem")

[Queuecumber]

As far as I can tell, nginx doesn't even support checking client certificate status using ocsp. Which is what we're talking about right? (If I'm wrong someone please correct me because that's the better solution)

[ntavares]

Although I like @jniebuhr 's "What you expected to happen" approach, I believe it might turn out to be a bit obscure. I see a very simple approach here: just allow another secret (or a configmap) specifically for the CSR, just as with the 'auth-tls-secret' annotation. If it is specified, then ssl_crt gets inserted in nginx.conf, otherwise nothing is done. It would then be up to the user to keep the secret/configmap up-to-date, and we could rely on nginx to reload automatically when the secret changed;

[bputt]

I agree with ntavares, we don't mind managing the file / update frequency on our side, we just need the option to configure it in the ingress controller

[ssboisen]

We're looking at using certificates to protect internal applications and would love to be able to set a ca.crl part in a secret passed via ingress annotation. The suggested approach in this thread seems good as it's in line with how the ca crt is provided to the ingress.

[rikatz]

Hi,

I'm working in this issue, I'm pretty busy but soon will have some PR to be reviewed

[Szymongib]

Hello,

I see PR is still open, are you going to drive that topic forward?

[rikatz]

I’m waiting for someone to take a look into the PR. I’ve just finished it, but there’s some test failing. Ricardo P. Katz Em 18 de dez de 2018, à(s) 07:46, Szymon Gibała <[email protected]> escreveu:

…

Hello, I see PR is still open, are you going to drive that topic forward? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Szymongib]

@rikatz Thank you for the response, looking forward to that feature!

[bputt]

any updates on this? Is the PR going to be included in the next release?

[fejta-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 sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Queuecumber]

/remove-lifecycle stale

[pakoAku]

Hey,

I wanted to ask if there are any news regarding the PR.