What is the correct ssl certificates configuration for multiple domain/sub-domains/servers?

Server
1

I’m trying to configure SSL certificate with Let’s Encrypt (from sslforfree.com), but after configuring, some customers complained about “Privacy Error”, specifically, one error was ERR_INVALID_CERT. Most of the complaints came from Chrome on Android. Windows 7 and up rendered green lock. Windows XP SP3 - rendered red, but after manually importing the certs to the customer’s PC, it rendered green.

My setup is on two servers:

Server A has: www.masterclub.es, es.octopon.me, …

Server B has: www.masterclub.co.il, octopon.me, …

I issued an SSL certificate with the help of sslforfree.com, that contains all of the domain names (17 in total), and bound it to all the sites in IIS, on both servers.

Some time before this trouble, I used the certificate only on Server B, and there were no complaints. So my suspicion is regarding the use of the same SSL certificate, on two different servers (and IP’s), whose reverse DNS records are different as well (I don’t know if it matters for validating a certificate…).

Please advise on the correct strategy of deploying ssl certificate(s) - should I issue one per server, or one per each domain, or one for all is good enough, or is it something else?
Also what could be the cause of ERR_INVALID_CERT on a few clients.
Please note, that I removed ssl from www.masterclub.es for now (production environment) .
While test.masterclub.es is still under ssl, and the privacy errors happened there as well, when i was testing from my android in chrome. Actually it still happens, i just checked. The error is ERR_CERT_AUTHORITY_INVALID.

Thanks.

2

Your server is sending the wrong intermediate certificate. Earlier this year, Let's Encrypt switched from an intermediate certificate called "Let's Encrypt Authority X1" to "Let's Encrypt Authority X3". Your certificate was issued under this new intermediate certificate (X3), but your web server is still sending the old one (X1). The reason why it's only failing intermittently, and only with some browsers, is that they might cache the intermediate certificate when you visit other sites using Let's Encrypt.

IIS (or rather a Windows component that IIS uses) has a bug that causes difficulties when you swap out the intermediate certificate - it might just keep on using the old one even though you've replaced it. Take a look at this post for a solution:

You can use SSL Labs to verify the issue is fixed. The relevant error is "This server's certificate chain is incomplete. Grade capped to B." If you hit "Clear cache" on that site, and the error disappears, you've successfully resolved this issue.

1 Like
3

Thanks for the reply.
I followed your advice, and now my phone renders the green lock :slight_smile:

Although i’m not sure if the error you mentioned has been removed from SSL Labs.
I mean it’s not there now, but I don’t remember seeing it before either…
Can you please verify?

Regarding the deployment: basically you are saying that i can use one certificate for all domains/servers or one certificate per each domain - it wouldn’t matter.
I was wondering what are the best practices (as in “do less and get more”…)

Thank you

4

Chain issues appear to be gone now, looks good to me.

Sorry, I missed that question initially.

If you're worried about clients without SNI (e.g. IE on Windows XP), using only one certificate per IP address (server) would be advisable. You can have up to 100 domains on the same certificate. That said, SNI support is fairly ubiquitous nowadays, so you probably don't have to worry about that unless you support a lot of outdated clients. In that case, bundling the certificates per domain might make them more manageable, especially if you regularly add or remove domains. In the end, it's up to you and your use-case. If you're fine with managing one big certificate, there's nothing wrong with sticking with that.

5

We don’t care about outdated browsers, but the ability to add/remove automatically without going through acme-challenge, and rebind for a bunch of domains, aliases, and sub-domains seems important.
It’s very tedious work to download 100 acme-challenge files, paste them to 100 sites, then verify that they are accessible, then run openssl to convert the certificate to pfx, and eventually rebind each domain…
The same goes for the renew certificate option.
Can you share pointers to command line scripts that would automate all 3 processes (add/remove/renew) for IIS ?

I think that in my case it’s more manageable to issue a certificate for each domain, although i’m not sure how to configure IIS 8.5 with multiple certs and SNI checked (a few months ago, i tried doing that, but i remember it produced errors, so i ended up with one big cert).
Please, your advice on that too.

6

There are a bunch of native clients for Windows on the client list. I’ve heard good things about both ACMESharp and letsencrypt-win-simple from people running IIS. letsencrypt-win-simple has pretty good auto-renewal support as well.

I haven’t used IIS in quite some time, but if memory serves me right, SNI “just works” on IIS versions that support it. You basically just associate the corresponding sites in IIS with the correct certificate. (I guess letsencrypt-win-simple will take care of this as well.)

1 Like
7

Thanks for the tip.

I tried letsencrypt-win-simple. Seems really simple to use, and what a big difference as opposed to doing it all manually…

In the process, I figured out that i need the --san option. Without it, name mismatch became an issue, because separate certificates were created for www and non www alternate names.

Now i’m trying to understand why test.masterclub.es keeps receiving 2 certificates for one site. The first is trusted but the other one is not - name mismatch. Every browser i could try rendered the green lock. But I’m still uncomfortable with this…
Can you please explain?
The mismatch comes from blog.masterclub.es which is legit, and has a separate certificate, with it’s own common name, and no other alt-names.

8

The second certificate is what clients without SNI support would receive. If a client without SNI sends a request, IIS doesn’t know which certificate it should use (it’s not aware of the hostname used in the request), so it falls back to the default certificate, which happens to be blog.masterclub.es. (Not sure how one would go about changing that default certificate in IIS.)

As long as all your clients support SNI, you’re good. A client without SNI would see an error because the name doesn’t match.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.