SSL Certificate Expiration Dates, Issuers, and "Full (Strict)" Setting

Why does one of these certificates come from Cloudflare and the other one comes from Google? They also have different validity lengths. Is this expected?

I’m also unable to enable “Full (Strict)” SSL mode on due to this:

However it works on perfectly:

How do I get them both to be from

Different certificate authorities have different maximum validity periods. For example, Google Trust Services has a maximum of 3 months while DigiCert has a maximum of 1 year. The certificate for is not really issued by Cloudflare, rather, it is issued by a branded subordinate CA managed by DigiCert.

You don’t. It would not fix the issue as the error you are seeing on has nothing to do with who issued the edge certificate.

To fix the issue you need a valid certificate for on your origin server. I recommend you pause Cloudflare on the domain until you are able to connect to your origin server over HTTPS.

You either have a valid certificate for on your origin server or the SSL mode is not set to Full (strict).


They’re both configured in exactly the same way. Cloudflare just so happens to have given a GTS cert and a Cloudflare cert, so that’s why get’s an error. They’re both set to “Full (Strict)”. I really don’t understand why they’ve issued a Google cert for as both domains are set up in the same way.

I need Cloudflare to issue an cert for just like it did for

Trust me, it is not. If there was an issue with the edge certificate for your browser would not even let you connect to Cloudflare’s servers. As the error you are seeing is being returned by Cloudflare, you have already successfully connected to Cloudflare’s servers. If you take a look at the “What happened?” section on the page, you will see that “The origin web server does not have a valid certificate.”

Cloudflare uses multiple certificate authorities to issue edge certificates. You cannot choose the certificate authority unless you purchase Advanced Certificate Manager. But like I have already said, the edge certificate issuer has nothing to do with the error you are seeing.

When using the Full (strict) SSL mode, Cloudflare requires that the origin server presents a valid certificate for the domain. This certificate is separate from the edge certificate.

Client <---[Edge Certificate]---> Cloudflare Server <---[Origin Server Certificate]---> Origin Server

If your origin server only has a certificate for, it will naturally not be valid for, causing Cloudflare to return this error.

Assuming and have the same origin server, you may be able to solve the issue by replacing the A/AAAA records on with a CNAME record pointing to This is due to the way Cloudflare validates origin server certificates (it accepts certificates valid for the domain name or the CNAME target the domain points to).

1 Like

The really ironic thing is, though, is that * and * BOTH don’t have valid origin certificates, as the hosting provider on that wildcard (Proton) cannot provide wildcard certs. So why does * work but * doesn’t?

For reference, the wildcards on both domains are exactly the same record and they are both proxied. Universal SSL is also enabled for both. If you need anymore info please let me know.

I appreciate your help and the explanations you have given. :slight_smile:

I cannot say without knowing the exact origin server configuration. I recommend you pause Cloudflare on so we can see what certificate the origin server is returning.

It’ll just be invalid and show a “Your connection is not private” message with an invalid cert for the * subdomain.

This is one of the reasons why I moved to Cloudflare - to fix the wildcard SSL. It works when I have it set to “Full” instead of “Full (Strict)”. I understand the reasoning now, with it being an invalid origin cert for both domains, but why * still works seems very strange to me. Why is Cloudflare accepting that invalid origin cert then?

Happy to change it back to “Full”, but I’d rather fix this if possible rather than use a loophole and lower the security (since that’s the whole point of Cloudflare).

I can unproxy both wildcard records and change the setting back to “Full”, if this will allow us to see the origin certificate in a browser rather than pausing Cloudflare altogether?

Never mind. My browser was caching the cert. I’ve flushed the DNS and now they both show as invalid, so NOW it makes sense.

Will change both domains back to “Full”. Thanks for your help!

If the origin server has a valid certificate for but not *, you can replace the A/AAAA record on * with a CNAME record pointing to You should then still be able to use Full (strict) due to how Cloudflare validates the origin certificate. The same should work for IN A

Full SSL mode is not secure so I strongly recommend you try the method I described above.


Oh wow. Never knew you could do that. Let me try!

Just changed that over now - using robots.txt as an example file, can you access both now?

Neither, actually. The former returns an origin SSL certificate error while the latter returns a connection error (HTTP 522). Could you send a screenshot of your current DNS records on both domains?

I saw that error too, but I think it’s working now. Can you try again please?

Oh wait - silly me. For both domains, the root doesn’t point to Proton - only the wildcards.

Will have to change both to “Full” by the looks of it and change the records back. :frowning:

As you might have noticed, and work fine while does not. The reason for this is that the origin is a shared hosting provider that uses the SNI to determine which certificate to use. The server only accepts and - an SNI of causes the server to return a certificate for which Cloudflare naturally doesn’t consider valid for

$ openssl s_client -servername -connect 2>/dev/null | grep 'subject'

$ openssl s_client -servername -connect 2>/dev/null | grep 'subject'

$ openssl s_client -servername -connect 2>/dev/null | grep 'subject'

As for why returns a connection error, that is because you are using as a Workers Custom Domain. Workers Custom Domains point to a “discard address” internally, so creating a CNAME record pointing to a Workers Custom Domain will cause a connection error.

To sum it up, your hosting provider’s setup is not compatible with the “CNAME trick”.

1 Like

That said, I do have some other subdomains on that are pointed to Proton with valid SSL’s, so maybe I could use this trick in that way? is set up with Proton, so if I point * to and set it to “Full (Strict)”, would that work?

Does it matter whether Proton has issued the cert to or Can’t recall which one they’ve issued it for that subdomain when you look in the “Common Name” field.

Please let me know @albert and I am happy to go forward with this.

I’ve changed it all back to “Full” and the old DNS records for the time being.

Yeah, it was me being stupid. The roots don’t point to Proton. They used to a couple of years ago which is probably why I thought that.

Lol. Brainfart.

The “CNAME trick” does not really work for shared hosting. Even if you use Full non-strict, Proton still probably handles requests using the Host header (which would still be even if * points to Unless you configured Proton to accept *, Proton would not know how to handle requests for