Need help on "urn:acme:error:unauthorized"

Please fill out the fields below so we can help you better.

My domain is:

I ran this command: le --account-key /path/to/account.key --csr /path/to/request.pem --acme-dir /path/to/acme-dir/

It produced this output:
Parsing account key…
Parsing CSR…
Registering account…
Already registered!
Signing certificate…
Traceback (most recent call last):
File “/usr/bin/le”, line 198, in
File “/usr/bin/le”, line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER,
File “/usr/bin/le”, line 161, in get_crt
raise ValueError(“Error signing certificate: {0} {1}”.format(code, result))
ValueError: Error signing certificate: 403 {
“type”: “urn:acme:error:unauthorized”,
“detail”: “Error creating new cert :: Authorizations for these names not found or expired:”,
“status”: 403

My operating system is (include version):
Debian Testing (stretch)

My web server is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

the Client in use is
it work the same way it works on other hosts. I can’t see local differences.
One thing to note: while validation happen tcpdump do NOT show ANY inbound http traffic

Can I delete “expired Authorizations” ?
Is a hostname “*test*.$domain” problematic?


Hello, once again.

is there anybody already hit the same error?

Any response would be fine.

Oh! I just realized the host tries once per day to renew the certificate (cron.daily, every day the same error)
The cronbob is disabled for now. I may wait a week to see if that help…


One thing I see is:

osiris@desktop ~ $ dig +dnssec ANY

; <<>> DiG 9.10.3-P4 <<>> +dnssec ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9254
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:	3536	IN	AAAA	2001:a60:f0b4:e501:205:69ff:fe79:e9dd	3536	IN	RRSIG	AAAA 10 3 3600 20170303054847 20170217054851 41766 gkK1hBCV34GdTWRTnLjZDfslffrqzhiIhsn7QdpTj/FLhW7z5nuJwVxD ydWs+iuDsSIuO/9B1bI+b+93hedax6EFkGUAeZNc4it1TxTqg9S/5ZRe yJ4VOdTJfG2TW6ZheMW//bTx6AtMKqUic9jDJnEvAykqU3j1c3FeXUkN jzb7v5YzKGErdX0iqDUF2zxmwZ85Ectrt54JKW1xqyV8BSWdTTzZxpwe ZpSMwcwYS1c58PMO5qD7eYX9jauz9vun/dKkdBAPuaCiRkboFAYDb0qp tWh9Stjdfkjzd+p5gfwl7GCoBs8ZcjtMuR9JFSaBF+TaBvifa1usF3h8 sIFNkw==


osiris@desktop ~ $ 

There’s only an IPv6 address configured for That isn’t a problem on its own. Let’s Encrypt happily connects to IPv6-only hosts.


osiris@desktop ~ $ telnet 80
Trying 2001:a60:f0b4:e501:205:69ff:fe79:e9dd...
telnet: connect to address 2001:a60:f0b4:e501:205:69ff:fe79:e9dd: Connection refused
osiris@desktop ~ $ 

That’s not helping! Is your webserver configured properly?


thanks for having a look. Yes, the webserver was down.
It’s usually up only for validation (and now by manual interaction)

$ echo OK > /path/to/webroot/.well-known/acme-challenge/test
$ curl

The acme-tiny client doesn’t really offer much of verbose logging I’m afraid… Also, it has been 7 months since it was updated. Although I don’t know if it really is a client problem, it could be…

Is there a reason why you chose acme-tiny? If you didn’t have a definitive reason for it, I’d suggest to try another (lightweight) client from the ACME client implementation list. Obviously, the Bash clients are very lightweight and has excellent documentation in the README and GetSSL is very nice too. :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.