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: prod.kuimba.info

I ran this command:

It produced this output:

My web server is (include version): nginx/1.10.3 (Ubuntu)

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

My hosting provider, if applicable, is: AWS

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

Hello all,

I am using certbot to get certificate for my site. My site is using Cloudflare with SSL setting is Full (strict) and I am using universal certificate. I have this option on Cloudflare “Always use HTTPS” turn ON (which basically means it will redirect all HTTP traffic to HTTPS). I’ve use this command "sudo certbot certonly --rsa-key-size 2048 --nginx -d <domain_name> --agree-tos --email " to obtain let’s encrypt cert. However, this only works with “Always use HTTPS” turn OFF. Furthermore, if I have managed to obtain a certificate (by turning “Always use HTTPS” OFF), I can use the same command to renew the certificate and this work perfectly with “Always use HTTPS” turn on.
So here are my questions:

Obtaining a certificate fails when “Always use HTTPS” turn ON. I think this is because nginx plugin using http-01, and let’s encrypt server communicate with my site using HTTP, but all traffic are being redirect to HTTPS by Cloudflare and let’s encrypt server cannot handler that. Am I correct? And can you guys elaborate?

I am not really understand why renewing a certificate works fine with “Always use HTTPS” turn on. Can you help me to explain it? And can I renew an expired certificate with this setting?

Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/prod.kuimba.info/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/prod.kuimba.info/privkey.pem
Your cert will expire on 2018-11-11. 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”

Issue new certificate & renew will always have some kind of issue with CloudFlare turned on (and http challenges) because CloudFlare is in front of your server & might sent the validation server a cached response (this case, 404 error)

vietthang207:

Furthermore, if I have managed to obtain a certificate (by turning “Always use HTTPS” OFF), I can use the same command to renew the certificate and this work perfectly with “Always use HTTPS” turn on.

I’m not sure how this works… Maybe it’s related to how Cloudflare redirects? (I’ll try to dig into some CF posts & see what’s going on)

Obtaining a certificate fails when “Always use HTTPS” turn ON. I think this is because nginx plugin using http-01, and let’s encrypt server communicate with my site using HTTP, but all traffic are being redirect to HTTPS by Cloudflare and let’s encrypt server cannot handler that. Am I correct? And can you guys elaborate?

The Let’s Encrypt server is fine with redirections to HTTPS during the validation process.

I think what you might be seeing is that if your origin server doesn’t have a certificate yet, CloudFlare itself refuses to proxy connections to it with the settings that you refer to. That is, in CloudFlare’s system design, these settings are only intended to be used after your origin server already has a certificate in place.

I haven’t consulted CloudFlare’s documentation to confirm this, so this is only a guess.

I think what you might be seeing is that if your origin server doesn’t have a certificate yet, CloudFlare itself refuses to proxy connections to it with the settings that you refer to. That is, in CloudFlare’s system design, these settings are only intended to be used after your origin server already has a certificate in place.

I suspect this behavior too, but I haven’t found any supporting document yet.

Do you have any other valid certificate in use before request an let’s encrypt certificate on those domains? (That reported unauthorized?)

(Cause Cloudflare “SSL (strict)” is defined as

You will need to have your server configured to answer HTTPS connections, with a valid SSL certificate. This certificate must be signed by a certificate authority that is trusted by Cloudflare, have an expiration date in the future, and respond for the request domain name (hostname).

… cloudflare will refuse to connect to your site via https… (I guess they also try to redirect let’s encrypt validation server to the https version of challenges file…)

Maybe CloudFlare should have a “SSL (strict, once a certificate exists)” that distinguishes between pre-issuance and post-issuance automatically. Otherwise, I guess CloudFlare users will often have to toggle this setting manually.

However, @vietthang207, you can also get a certificate from Let’s Encrypt using the DNS-01 ACME validation method, where you create DNS records rather than files on your web server in order to prove your control over the domain name. Several Let’s Encrypt client applications have good support for CloudFlare’s DNS API, and so if you also have your DNS managed by CloudFlare, you could use this method to obtain certificates for your origin server without requiring an inbound HTTP or HTTPS connection. Therefore, this method can be used whether or not your web server is initially reachable from the Internet. And so you could use it to obtain certificates for an origin server even with the Strict setting.

Maybe CloudFlare should have a “SSL (strict, once a certificate exists)” that distinguishes between pre-issuance and post-issuance automatically. Otherwise, I guess CloudFlare users will often have to toggle this setting manually.

I actually believe that ‘SSL (full)’ is turned on by default… User need to manually choose to turn on strict …