letsencrypt now wants ACMEv2 #1448
Comments
|
:O Thanks for reporting this! Ah I notice now that it was not as urgent as I feared, only account creation has stopped, not core functionality for the running services for those with accounts already. Now it is only as urgent as this is blocking anyone from working with this helm chart etc. =/ ping @jupyterhub/mybinder-org-operators and others who this may concern. |
|
Looks like we need to switch to cert-manager as ACMEv2 isn't supported jetstack/kube-lego#301 Related z2jh issues |
|
+1 |
|
This has hit me as well. I've had to just forego ssl for now. |
|
There are instructions for using cert-manager in #755 |
This puts people directly into https://github.com/yuvipanda/jupyter-desktop, with an XFCE environment. There's no specific use case for this yet, but I'm sure we'll find one soon enough! This has the same home directories as datahub. No HTTPS yet, because of jupyterhub/zero-to-jupyterhub-k8s#1448
|
I'm working on replacing the current kube-lego based autohttps with something much simpler based on upstream certbot that should help fix this without requiring the super heavy-weight cert-manager. https://gist.github.com/yuvipanda/64756b1bdc34faf1f20175ae5ea0e98e contains a minimal working example. I'm working on a PR to z2jh for this. |
When we [picked](jupyterhub#229) kube-lego to do automatic HTTPS in 2017, it seemed the easiest and most kubernetes native way to do let's encrypt based HTTPS. It was fairly simple, and worked pretty well for our use case. Users of this chart could set up HTTPS without having to know anything about certificates, challenges or let's encrypt. Life was good. Life moves on, and so does code. kube-lego was deprecated in favor of [cert-manager](https://github.com/jetstack/cert-manager), which was far more general. It wasn't tied to Let's Encrypt, and could do a lot more things. It was far more kubernetes native, and slicker. However, this came with a massive increase in complexity, which is justifyable if you need many certificates in many situations. However, for the most common case of just one certificate per hub, this was super massive overkill. This PR replaces the current autohttps with autocertbot, a tiny wrapper around the recommended upstream let's encrypt software - [certbot](https://certbot.eff.org/). certbot requires persistent storage under /etc/letsencrypt, and we would prefer to not. This was the primary reason I picked kube-lego over certbot back in the day. However, a small wrapper script that sync's the contents of /etc/letsencrypt to a kubernetes secret when needed is small, easy to reason about and solves all our problems. This PR should be fully backwards compatible. autocertbot should be able to renew certificates that kube-lego was handling before, and issue new certificates as well. Since it is just wrapping upstream certbot, there are fewer chances of a deprecation hitting us hard. Fixes jupyterhub#1448
|
This issue has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/jupyterhub-upgrade-steps-for-https-acmev2/4029/1 |
I just tried to set up another z2jh and the autohttps pod is reporting the following error:
"Error while processing certificate requests: 403 urn:acme:error:unauthorized: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details." context=kubelegoAt https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 they sent out the following PSA yesterday: "The second production brownout for new ACMEv1 registrations has begun."
The text was updated successfully, but these errors were encountered: