Fastly Complaining About Self-signed Cert
-
I'm trying to use Fastly as a CDN for my Wordpress site, but it is complaining that I'm using a self-signed cert.
The site is on a subdomain, and I am using the "Let's Encrypt Prod" certificate provider. When I do an SSL check via SSLLabs (https://www.ssllabs.com/ssltest/), I see the following:
Certificate #1: EC 384 bits (SHA256withRSA) Subject: subdomain.mydomain.com Common names subdomain.mydomain.com Alternative names subdomain.mydomain.com Trusted: YesThat's great. But there's a second certificate:
Certificate #2: RSA 2048 bits (SHA256withRSA) No SNI Subject cloudron-2021-11-17T01:23:33.708Z Common names cloudron-2021-11-17T01:23:33.708Z Alternative names - INVALID Trusted No NOT TRUSTEDThis seems to be tripping Fastly up.
Why does this second certificate exist? Is there any recommended way to move forward?
-
Check the advanced settings for that domain, and let us know the configuration.
-
I have not provided a fallback cert. I see now that a self-signed cert is automatically provided if the optional fallback cert is not provided. What are my options here? The self-signed cert is causing problems, but I don't want to have to manually generate and upload a new cert every couple months.
-
Does anyone have a recommended course of action?
I should add that I am fine with keeping the fallback cert on the main domain used for access to my cloudron dashboard. But one of my additional domains needs to NOT use a self-signed cert as fallback, or I cannot use my CDN or use the MainWP Wordpress plugin, since both complain about use of self-signed certs (apparently even when it's not the primary cert).
I really need to get this resolved, and any assistance will be much appreciated!
-
@omen said in Fastly Complaining About Self-signed Cert:
Why does this second certificate exist? Is there any recommended way to move forward?
The ssllabs website is testing the certs in 2 cases - with SNI and without SNI. The SNI case works and this is the usual setup these days which is required to work. The non-SNI case does not work on websites/apps that use a "shared" IP which is the case with Cloudron (i.e all your apps are on different subdomains but share an IP address). The non-SNI case needs to work only if you have some very old legacy devices accessing your website. In shared hosting scenarios like Cloudron, only TLS SNI can work because without it nginx cannot figure what cert to provide during TLS negotiation.
In short, the Cloudron TLS setup is fine and the ssllabs testing results is also fine. Nothing to worry about.
-
@omen OK, I figured out how configure Fastly now...
Please configure it like below:- Enable TLS - Yes
- Verify Certificate - Yes
- Certificate hostname - In my case, it is wildcard. But since you use the 'manual' provider, the hostname is
subdomain.example.com. - SNI hostname - this is
subdomain.example.com.
With the above settings, fastly serves up pages fine on http.
One thing to remember is, because you are using "manual" DNS provider, Cloudron requires "http" callbacks for Let's Encrypt to work. I am not sure how this works in fastly, does it allow you to have some URLs that are not "cached" ? I guess one way is to call the Cloudron app subdomain as "website.domain.com" but the domain in fastly should be something else like "realwebsite.domain.com" (meaning, name it different). This way, manual setting on Cloudron can continue to use HTTP reliably to get certificates.
If you want the domain names to be same, you have to use one of the automated DNS providers in Cloudron.
