Issuing certificates to non-root user

Hello, using a wrapper I wrote around https://github.com/unixcharles/acme-client, I have no problem obtaining certificates via the the staging endpoint BUT I am am having problems issuing certificates using the production endpoint - https://acme-v02.api.letsencrypt.org/directory

1st theory:
In attempting to understand why this might be happening, I would like to know if using a non-root account (docker container that issues the cli command to obtain certificate is running as non-root user ) would affect my ability to obtain certificates via production endpoint/directory?

Thank you.

I don’t know about how that client is implemented, but there should be no major differences between using the production and staging endpoints. This sounds very strange.

Can you tell us more about what’s going wrong?


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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on 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 version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

Thanks for getting back to me. I agree that discrepancy between staging and production is strange - was under the impression that my tests using the staging endpoints would catch any issues.

The information requested:

  • I ran this command:

    • cli order_certs production
      • the above is a wrapper around function order = client.new_order(identifiers: ['example.com']) in acme-client*
  • It produced this output:

    • 500: {"id": "internal_server_error", "message": "Server was unable to give you a response." }
  • My web server is (include version):
    -nginx version: nginx/1.15.10

    • but since I am performing a DNS challenge I do not think that my web server is important (do correct me if I am wrong).
  • The operating system my web server runs on is (include version):

    • Ubuntu bionic via docker
  • 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

I am going to check with DigitalOcean to see if the issue is from their end before hitting up the author of the client. Please do let me know if you think of any point I might be missing.

Thanks.

Hi @pnotes

there are refused - nameserver answers ( https://check-your-website.server-daten.de/?q=uzoagu.com )

Host T IP-Address is auth. ∑ Queries ∑ Timeout
uzoagu.com Refused yes 1 0
www.uzoagu.com Refused yes 1 0

Same checking CAA

CAA - Entries

Domainname flag Name Value ∑ Queries ∑ Timeout
uzoagu.com -5 Refused - The name server refuses to perform the specified operation for policy reasons 1 0

and TXT entries:

TXT - Entries

Domainname TXT Entry Status ∑ Queries ∑ Timeout
uzoagu.com Refused - The name server refuses to perform the specified operation for policy reasons 1 0
_acme-challenge.uzoagu.com Refused - The name server refuses to perform the specified operation for policy reasons 1 0
_acme-challenge.uzoagu.com.uzoagu.com Refused - The name server refuses to perform the specified operation for policy reasons 1 0

Rechecked with Unboundtest to see, if my tool doesn't have a bug - the same:

https://unboundtest.com/m/CAA/dev.uzoagu.com/UHTUQDSD

reports a SERVFAIL.

Does it have more detailed error logs? I don't think that's an error message from Let's Encrypt.

1 Like

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