Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACMEv1 disabled by Let's Encrypt, can't automatically secure with HTTPS #228

Closed
judges119 opened this issue Dec 24, 2019 · 2 comments · Fixed by #240
Closed

ACMEv1 disabled by Let's Encrypt, can't automatically secure with HTTPS #228

judges119 opened this issue Dec 24, 2019 · 2 comments · Fixed by #240
Labels
Milestone

Comments

@judges119
Copy link

Describe the bug

When you first create and configure and instance and set it to use automatic HTTPS security with Let's Encrypt, when you first run and try and get a new certificate issued you are presented with the following warning in the logs:

2019/12/24 11:15:10 http: TLS handshake error from 192.168.1.203:53822: 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.

The log links to the Let's Encrypt community which says they are dropping support for ACMEv1 and browning out the registration service.

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

  1. Download and unzip release
  2. follow confiration, set yourself as secure with automatic certificates
  3. generate keys
  4. start writefreely
  5. visit instance URL
  6. receive TLS Handshake error
  7. SSL no longer works

Expected behavior

The internal Let's Encrypt HTTPS negotiation should be done via ACMEv2

Application configuration

  • Single mode
  • Database? [sqlite]
  • Open registration? [yes]
  • Federation enabled? [yes]

Version or last commit:
v0.11.2

@techknowlogick
Copy link
Contributor

This is an error that Gitea also had, and we resolved it by pinning a newer version of golang.org/x/crypto which supports acmev2 (see go-gitea/gitea#9056 as an example PR)

@thebaer thebaer added the bug label Jan 14, 2020
@thebaer
Copy link
Member

thebaer commented Jan 14, 2020

Thanks for the report, @judges119 -- and for the insight, @techknowlogick! If you're interested in contributing that same fix as a PR here, we'll be happy to accept it. Otherwise the team will get to it when we can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

3 participants