Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command:
sudo go run . &
then try to connect to the server through my browser
It produced this output:
2022/05/25 23:02:24 http: TLS handshake error from 185.169.255.84:39716: acme/autocert: unable to satisfy "https://acme-v02.api.letsencrypt.org/acme/authz-v3/112566445456" for domain "elephorum.com": no viable challenge type found
2022/05/25 23:02:24 http: TLS handshake error from 185.169.255.84:40034: acme/autocert: missing certificate
My web server is (include version):
go 1.17
The operating system my web server runs on is (include version):
ubuntu-2004-focal-v20220419
My hosting provider, if applicable, is:
Google GCP Compute Engine
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
no
Also, I don't fully understand autocert.. The authorization is deactivated, which is something only an ACME client can do (if the ACME server disabled the authz, it would have been called "revoked"). But all the challenges of the authz are still "pending", so nothing has been done with them! They were apparently not triggered to perform the challenge at all. And all three possible challenges are there: there are no other challenges currently available.
So I don't understand why autocert is complaining. It should either have used the authz and not deactivate it and use one of the challenges. Or ignore the deactivated authz and generate a new one?
Well, I'd have to hack the server of OP, search for every main.go file present and check every file manually to see if it has any relationship with Let's Encrypt at all Surely not impossible.
I wonder if something went horribly wrong with the assumption that code makes about nextTyp being consistent between authorizations. My memory is very foggy but I think Boulder deletes unused challenges once an authorization becomes valid. An order which was created with mixed cached valid/pending authorizations may break autocert's assumptions.
I'm gonna vote for "autocert bug", not that it especially helps OP.
Sorry guys, I am new to go and developing websites.
So when I have logged in to the VM instance I have created on GCP, and connected to it through ssh, I just run sudo go run . & in the directory containing the code of the server, and a main.go file.
In the main.go, I have imported "golang.org/x/crypto/acme/autocert", created an autocert.Manager with Prompt, HostPolicy, and Cache fields filled in.
Then I created two threads, one with HTTPHandler(nil), listening and serving at port 80, another thread listening and serving the real content of my website with at port 443.
So I have no idea what web server I am running except it is written in go 1.17.
Would you mind giving me some example of what you are expecting for My web server is (include version):? Is it something like Apache, or Nginx? I am not using any of those.