Certbot always issues bad certificate with: Fake LE Intermediate X1

Help
1

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

My domain is: core.codekraft.it

I ran this command: certbot certonly --webroot

It produced this output:

 IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at
       /etc/certbot/live/core.codekraft.it/fullchain.pem. Your cert will
       expire on 2017-09-20. 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):

Server version: Apache/2.4.25 (Linux/SUSE)
Server built:   2017-06-02 07:45:40.000000000 +0000

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

LSB Version:    n/a
Distributor ID: openSUSE
Description:    openSUSE Tumbleweed
Release:        20170619
Codename:       n/a

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

Everytime I issue a new certificate it gives me this error:

NET::ERR_CERT_AUTHORITY_INVALID

I assume is because is using the ā€œstagingā€ intermediate certificate Fake LE Intermediate X1 but witouth the --staging options.

How can I issue the certificate which use Letā€™s Encrypt Authority X3 (IdenTrust cross-signed) which is valid for the browser?

2

Check /etc/letsencrypt/cli.ini for staging, or possibly test_cert or server, settings.

Certbot uses production by default, but certain OS packages override the default to staging.

1 Like
3

I just checked and I changed the comments from this:

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

to this:

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

andā€¦YESSS MANN!

You saved me, I was beginning to feel really frustrated

I tried in many ways before submitting this post :smile:

1 Like
4

I have the same issue. In my case, I do not have a cli.ini file under /etc/letsencrypt/. I tried creating one and inserting the server = line but I still get certificates from the staging server.

This is happening on an Ubuntu 14.04 LTS server where LetsEncrypt was previously installed by source. I just completely deleted everything related to LetsEncrypt and started using Certbotā€™s new PPA.

5

@RaalFy, what command are you running?

6

@schoen Thanks for responding.

The command Iā€™m running:
certbot certonly --webroot --webroot-path /var/www/ehc_simplesamlphp/www

Initially I tried with the following when testing to avoid hitting the limit:
certbot --staging certonly --webroot --webroot-path /var/www/ehc_simplesamlphp/www

7

Hi @RaalFy,

If you have an existing certificate from the staging server, this might somehow be trying to renew that with an equivalent certificate. Could you show me the output of certbot certificates or cat /etc/letsencrypt/renewal/*? Did you say that you actually edited a file in the latter directory?

8

Hi @schoen - Sure!

certbot certificates

Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Found the following certs:
  Certificate Name: account.domain.edu.zm
    Domains: account.domain.edu.zm
    Expiry Date: 2017-09-21 19:32:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/account.domain.edu.zm/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/account.domain.edu.zm/privkey.pem
-------------------------------------------------------------------------------

cat /etc/letsencrypt/renewal/

root@ip-172-31-34-128:~# cat /etc/letsencrypt/renewal/*
# renew_before_expiry = 30 days
version = 0.14.2
archive_dir = /etc/letsencrypt/archive/account.domain.edu.zm
cert = /etc/letsencrypt/live/account.domain.edu.zm/cert.pem
privkey = /etc/letsencrypt/live/account.domain.edu.zm/privkey.pem
chain = /etc/letsencrypt/live/account.domain.edu.zm/chain.pem
fullchain = /etc/letsencrypt/live/account.domain.edu.zm/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 57fc6e2f18f77e1bc94f3909d697c19a
webroot_path = /var/www/ehc_simplesamlphp/www,
server = https://acme-v01.api.letsencrypt.org/directory
[[webroot_map]]
account.domain.edu.zm = /var/www/ehc_simplesamlphp/www
root@ip-172-31-34-128:~#

I should also note that prior to my last attempt, I executed cp -r /etc/letsencrypt /opt && rm -rf /etc/letsencrypt/* to ensure no existing configuration scripts were used.

9

Could you tell us your real domain name?

Edit: since youā€™ve told me your domain name I see that there are valid certificates issued for it as recently as today, so I think thereā€™s something else strange going on. You are succeeding in getting valid Letā€™s Encrypt certificates issued, but your web server is somehow not configured to use them and is continuing to use the test certificate instead.

Is it possible that you have another server? If not, could you take a look in your configuration files to see where they tell your web server what certificate to use?

11

Thank you @Schoen for your help. The issue has been resolved.

I checked my web server (Apache) configuration. I had the following referencing the LetsEncrypt certificates:

SSLCertificateFile /etc/letsencrypt/live/account.domain.edu.zm/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/account.domain.edu.zm/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/account.domain.edu.zm/chain.pem

ls -l showed the files above are symbolic links to cert2.pem, chain2.pem, fullchain2.pem and privkey2.pem in the archive directory. Odd, so I checked the archive directory and found the following:

root@ip-172-31-34-128:# ls /etc/letsencrypt/archive/account.domain.edu.zm/
cert1.pem  cert2.pem  chain1.pem  chain2.pem  fullchain1.pem  fullchain2.pem  privkey1.pem  privkey2.pem

All files were issued today, the files with the number ā€˜2ā€™. were issued about 20 minutes after the files with ā€˜1ā€™. I took another backup of the /etc/letsencrypt directory and deleted all the symbolic links under the /etc/letsencrypt/live/account.domain.edu.zm directory and created new symbolic links referencing the files with 1, restarted apache and the HTTPS version of the site loads without errors, SSLLabs also shows that the certificate is now trusted.

Thank you lots for the assistance. I read about you and youā€™ve done some very important work for the EFF and Internet security/privacy as a whole. Iā€™m shocked you had the time to respond to a noob like :smiley:

Iā€™ll definitely stick around to help from time to time.

Thanks again,
Ralph

12

Iā€™m glad you could solve the problem! That seems to show that thereā€™s a way that test certs can replace real certs even without using --break-my-certs, which shouldnā€™t really be possibleā€¦

13

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