Hi my site is hosted with Dreamhost. I was usig SSL Lets Encrypt for free. I joined Cloudflare and the option to pay extra for SSL.
My lets encrypt SSL is not updating I keep getting warnings from Dreamhost. Do i need that as well. I thought my extra $5 buys SSL cerficate via Cloudflare. not sure what to do . I paid for SSL via Cloudflare.
Is there anywhere you can submit tickets or do I need to post my questions here?
Thanks
The dedicated SSL you bought is installed in Cloudflare’s server, not at DreamHost’s. Since Cloudflare terminate the SSL connection at their endpoint, Let’s Encrypt ACME server would have trouble connecting to your server, so I would recommend getting a self-signed certificate with DreamHost Self Signed SSL. After installing the certificate, please change the SSL mode at Cloudflare Dashboard to Full if you haven’t already.
If you chose to set DreamHost Self Signed SSL, you do not need to buy the unique IP they offered.
To submit tickets to Cloudflare support, please visit: https://support.cloudflare.com/requests/new
cool i think its sorted now
This is not my experience in a similar situation. I have lots of WPEngine sites behind CF, using the WPEngine Let’s Encrypt service. The ACME server connects to http://example.com/.well-known/acme-challenge/<something>
, so provided that is available you should have no issues.
If you are redirecting to HTTPS you are also OK, as ACME will follow the redirect. Just be careful that for the very first certificate request you have SSL Mode set to Flexible, as you probably don’t have any certificate yet on the backend. Once you have the first cert in place you are OK to set SSL Mode to Full or Strict as you prefer, and renewals will happen without issue.
I have seen lots of articles saying you should not redirect the /.well-known/acme-challenge/
directory. In my experience this is an unneeded complication. Provided you can read files in that directory, even after a redirect, ACME will issue the certificate.
The alternative is to use the DNS-01 method, which supports using the CF API (see Certbot documentation). Lots of articles you will see online (such as this on the CF Support pages) are out of date. Support for DNS-01 is now available in lots of clients, including Certbot.
Having a valid certificate on the origin is very handy, as you can be certain that going grey cloud will not immediately break due to a cert issue.
1 Like
You just said the exact opposite to the tanto259. and starting off by
saying this is not my experience. I have followed tanto259 so hopefully he
is right. Thankyou
Per this article:
https://support.cloudflare.com/hc/en-us/articles/214820528-How-to-Validate-a-Let-s-Encrypt-Certificate-on-a-Site-Already-Active-on-Cloudflare
As a note, the default method used for ACME authentication by the Let’s Encrypt client utilizes the DVSNI method. This will fail for a domain which has Cloudflare enabled as we terminate SSL (TLS) at our edge and the ACME server will never see the certificate the client presents at the origin.
and I have no idea how DreamHost do their domain validation. Therefore I suggest using selfsigned certs as Cloudflare can still use those to do a full ssl connection and it would still be easy to setup.
But I agree with your statement that:
It would be SSL, but without certificate validation, it’s not secure.
A self signed SSL will provide the same encryption as a normal SSL, albeit minus validation. Since connection is passing through Cloudflare, the visitor will see a valid Cloudflare-provided SSL, and once the data passes Cloudflare server will be re-encrypted by Cloudflare with the self-signed SSL back to the origin server.
Site visitor will not notice that self-signed is used. And, as long as the DNS setting is correct, Cloudflare will still connect to the correct origin, not an attacker’s server.
An active attacker can still MITM the connection between Cloudflare and the origin but it would be hard to do.
Another option is to use Cloudflare Origin SSL with the Full (Strict) mode, but not all people know how to install a SSL cert at the hosting provider.