Fastly Complaining About Self-signed Cert

[omen]

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: Yes

That'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 TRUSTED

This seems to be tripping Fastly up.

Why does this second certificate exist? Is there any recommended way to move forward?

[omen]

This same thing is causing issues with using the Wordpress plugin MainWP (https://mainwp.com/), which returns an error "HTTP error - SSL certificate problem: self signed certificate" when I try to connect other Wordpress Sites.

[robi]

Check the advanced settings for that domain, and let us know the configuration.

Visit https://my.domain.com/#/domains

[omen]

@robi Here's the settings.!

[omen]

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.

[omen]

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!

[girish]

@omen I am just signing up to fastly to understand how they setup the CDN. Hold on...

[girish]

OK, it's saying " We have saved your version and it's deploying across Fastly's network. Check it out in a minute (or less). " for a while now. Waiting.

[girish]

I am also seeing the same self signed cert issue (this is with their test domain, I have not added CNAME records etc). It seems to be some configuration on fastly side. If I skip TLS validation, it works but this shouldn't be required.

[girish]

@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.

[girish]

@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.