I can only get staging certificates

Help
1

When setting up the certificate (command output below) it used the staging server (apparently it shouldn’t by default?), so I get a certificate warning when trying to connect.
/etc/certbot/renewal/farfetchd.duckdns.org.conf contains this:

server = https://acme-staging.api.letsencrypt.org/directory

and when I try to change it to https://acme-v01.api.letsencrypt.org/directory and try to renew the certificate, it tells me this

Attempting to renew cert from /etc/certbot/renewal/farfetchd.duckdns.org.conf produced an unexpected error: You've asked to renew/replace a seemingly valid certificate with a test certificate (domains: farfetchd.duckdns.org). We will not do that unless you use the --break-my-certs flag!. Skipping.

even though the whole point of the config change is to not use the test certificate? It doesn’t seem to respect the server = setting at all, since the /var/log/certbot/letsencrypt.log file still shows that it’s trying to use staging…

This is the gitlab.ini file:

# this is the let's Encrypt config for our gitlab instance

# use the webroot authenticator. 
authenticator = webroot
# the following path needs to be served by our webserver
# to validate our domains
webroot-path = /srv/www/public

# generate certificates for the specified domains.
domains = farfetchd.duckdns.org

# register certs with the following email address
email = <redacted>

# use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

My domain is: farfetchd.duckdns.org

I ran this command: certbot certonly -c gitlab.ini

It produced this output:

Saving debug log to /var/log/certbot/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for farfetchd.duckdns.org
Using the webroot path /srv/www/public for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/certbot/live/farfetchd.duckdns.org/fullchain.pem. Your cert
   will expire on 2017-11-21. To obtain a new or tweaked version of
   this certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

My web server is (include version): nginx/1.12.1 (comes with GitLab)

The operating system my web server runs on is (include version): openSuSE Leap 42.3

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

2

Do you have an /etc/letsencrypt/cli.ini file?

3

No, there’s no /etc/letsencrypt directory at all.

edit: there is /etc/certbot/cli.ini though

4

That’s pretty weird, because our official Certbot never creates or checks /etc/certbot.

What are the contents of that file?

5 
# This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Certbot with
# "--help" to learn more about the available options.
#
# Note that these options apply automatically to all use of Certbot for
# obtaining or renewing certificates, so options specific to a single
# certificate on a system with several certificates should not be placed
# here.

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096

# The staging/testing server
server = https://acme-staging.api.letsencrypt.org/directory
# The production server.
# server = https://acme-v01.api.letsencrypt.org/directory

# Uncomment and update to register with the specified e-mail address
# email = foo@example.com

# Uncomment and update to generate certificates for the specified
# domains.
# domains = example.com, www.example.com

# Uncomment to use a text interface instead of ncurses
# text = True

# Uncomment
# agree-eula = True
# agree-tos = True
# renew-by-default = True

# Uncomment to use the standalone authenticator on port 443
# If you want to use port 443, you must use standalone-supported-challenges
# If you want to use port 80, you must use preferred-challenges = http-01
# authenticator = standalone
# standalone-supported-challenges = tls-sni-01
# preferred-challenges = tls-sni-01

# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
# authenticator = webroot
# webroot-path = /usr/share/nginx/html
# webroot-path = /srv/www/htdocs
6

Well, that explains why this is happening, if you see the “server =” line here. That will override your /etc/certbot/renewal/farfetchd.duckdns.org.conf because items in an .ini file are regarded by Certbot as having been typed on the command line, which has the highest priority. If you change it, you should no longer have the problem that you’ve been having.

However, I don’t know where this file came from or why it set this default. Our official Certbot release does not include (or check) this file at all.

7

Thanks! The file is in the official openSuSE certbot package, by the way.

8

Huh, it sure is! We should probably get in touch with the maintainers.

@SwartzCr, do you have any contacts with SuSE packagers? They seem to have made a default .ini file that uses the staging server instead of the production server.

9

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