Keep getting Fake LE Intermediate X1 Issuer

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

My domain is:

I ran this command: I ran a script that I got from I believe the pertinent lines are:

#./letsencrypt-auto certonly --standalone --test-cert --break-my-certs -d $mydomain --standalone-supported-challenges http-01 --http-01-port 9999 --renew-by-default --email $myemail --agree-tos
./letsencrypt-auto certonly --standalone -d $mydomain --standalone-supported-challenges http-01 --http-01-port 9999 --renew-by-default --email $myemail --agree-tos

I was originally using the first line, but once it started working, I commented it out and started using the second line. I also updated the passwords seen in the script from “changeit” to a new password. This caused problems with the .keystore file, so I renamed the .keystore file to .keystore2 and just had the script generate a new .keystore file.

It produced this output:

The standalone specific supported challenges flag is deprecated. Please use the --preferred-challenges flag instead.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges

 - Congratulations! Your certificate and chain have been saved at:
   Your key file has been saved at:
   Your cert will expire on 2017-11-12. To obtain a new or tweaked
   version of this certificate in the future, simply run
   letsencrypt-auto again. To non-interactively renew *all* of your
   certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:
   Donating to EFF:          

I believe I grabbed the right output here, the rest seems to be from the git command and the keytool commands and starting jira.

My web server is (include version): Apache Tomcat 6.0.20

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

My hosting provider, if applicable, is: ???

I can login to a root shell on my machine (yes or no, or I don’t know): No? I can sudo things but I can’t log into the server as root

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

I know both our Ubuntu and Tomcat are very old. We’re going to update soon but we want to figure out how to get https working before doing so

Are you sure Apache is pointing to the right certificate? Can you paste the output of openssl x509 -in /etc/letsencrypt/live/ -noout -text? (None of this output will display sensitive information, it’s exactly the same information in the public certificate presented to anyone who visits that domain or looks at the certificate transparency logs.)

Speaking of which, I don’t see in the certificate transparency logs, so it appears this was never actually issued. Is this your real domain?

It looks like this advice is very old because the names of letsencrypt-auto, --standalone-supported-challenges, and --renew-by-defaulthave all changed since then (tocertbot-auto ,--preferred-challenges, and --force-renewal`).

Anyway, I agree with @jared.m that it would be useful to see that information, and also you could look at /etc/letsencrypt/renewal/ to see if it's still hard-coded to point to the staging server (I'm not sure why the second command wouldn't have changed that).

Maybe it was only ever issued by the staging server and never by the production server? The staging server doesn't log in CT.

Yes, is my real domain (I think - I’m doing all this because I have downtime at work, not because I am well suited to do this). I had to sudo the command to get more than permission denied, but once I did:

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
            Not Before: Aug 14 19:02:00 2017 GMT
            Not After : Nov 12 19:02:00 2017 GMT
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            Authority Information Access:
                OCSP - URI:
                CA Issuers - URI:

            X509v3 Subject Alternative Name:
            X509v3 Certificate Policies:
                  User Notice:
                    Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at

    Signature Algorithm: sha256WithRSAEncryption

That looks like a real certificate to me. Can you take a look at your Apache configs and verify that it’s set to use that certificate? It’s also possible you need to reload Apache to force it to use this certificate. Usually this is done by virtue of the fact that Apache must be stopped before and restarted after using --standalone, as Apache and Certbot cannot listen on port 80 simultaneously, but if you’re running on a nonstandard HTTP port, then you may not have reloaded Apache after issuance of the real certificate.

Yeah, I know it’s a little old, but it has comments from earlier this year that indicate it still works, and it was the best thing I could find. contains:
# renew_before_expiry = 30 days
version = 0.17.0
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

# Options used in the renewal process
standalone_supported_challenges = http-01
account = 364054c5dfecc15aca13dddb2982fe4c
http01_port = 9999
authenticator = standalone
installer = None
server =

I have been restarting the web server. In Jira’s install folder in /opt/, there’s /bin/ and /bin/ which is what I’ve been using to restart the server (again, I assume - I know after running I can’t access the site at all). Jira runs on 8080 (HTTP) and 8334 (HTTPS). I’m not sure how to check Apache’s configs

There are six certificates in CT for this name today and none before today. So, you’re going to be rate-limited and unable to issue any more certificates like this for a week!

As we saw from the openssl output, your current certificate in /etc/letsencrypt/live/ is valid and was issued by the production server, not by the test server. So the problem now is not issuing any more certificates but getting Jira to use the new certificate. This probably calls for debugging or refining your JKS import process to correctly get the data from /etc/letsencrypt/live/ into the JKS file that Jira is using. That’s my impression, anyway.

CT = Certificate Transparency? Jared said he couldn’t see any entries. How do I even check?

1 Like


Google's logs lag behind a bit, and the earliest certificate is barely 2 hours old. They only just showed up.

Well, there are a lot of ways, like downloading them yourself. But is good.

They also display the delay:

This was enough to point me in the right direction and everything is up and working now. Thanks!

Regarding the number of certificates I can be issued within a certain time period, the script I have that gets a new certificate is placed in cron.monthly - is renewing once every month going to be a problem?

While once a month will certainly not hit any rate limits, the best practices method for this is to remove the ‘renew-by-default’ flag (also making sure not to have the synonymous ‘force-renewal’ flag set) and set the renewal to run in cron twice daily. Certbot, without the flags mentioned, will only attempt renewal of certificates expiring within 30 days. Running twice a day will help catch intermittent failures early and give the system plenty of chances to attempt renewal at different times of day.

We really encourage a very different approach — our certbot renew script is meant to be run at least once per day, but only attempts to renew a certificate when that particular certificate is less than 30 days from expiry. There are various arguments in favor of this, for example the fact that the certificate authority service itself has intermittent outages (I would estimate that it's only been up around 99.5% of the time, although the people running it may have more accurate numbers), or that a misconfiguration could cause a renewal to fail. In that case, it would be good to have more lead time before the expiry in order to notice and be able to retry or remedy the problem.

Also, if you have many certificates, there can be benefits to spreading out their renewals because of rate limits (although if you have very many certificates, you'll probably need to plan the exact renewal schedule).

Under Let's Encrypt's rules, you're allowed to renew a given certificate about once per week if you feel you really need to.

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