Since I remember that we are using at least two servers for load balancing, my first guess is that one of the apaches has the wrong cert-file in place.

For me:

• https://perlmonks.pairsite.com/ works
• https://www.perlmonks.com/ works too, but with a *.perlmonks.org (?) cert.

all other combinations I tried required a manual exception.

update

Forgot to test *.perlmonks.net with Firefox, but they seem to work fine with my mobile browser.

dig shows 3 IPs being round robin'd (robinned?). The Let's Encrypt SAN cert works on (www\.)?perlmonks\.(org)|(com)|(net), but the pairsite wildcard cert will only work on the pairsite domain, one subdomain deep. So www.perlmonks.pairsite.com will not work, authentication wise, with either cert. 3 Servers, 8 urls, 2 certs, one of which expires every 90 days, not the most enjoyable way to spend free time, I'm sure.

Interestingly it looks like it has been setup correctly on 2 of the 3 servers

$ host www.perlmonks.org 
www.perlmonks.org is an alias for perlmonks.org.
perlmonks.org has address 209.197.123.153
perlmonks.org has address 66.39.54.27
perlmonks.org has address 216.92.34.251


$ openssl s_client -showcerts -servername www.perlmonks.org -connect 2
+09.197.123.153:443 </dev/null 2>&1| grep subject
subject=/C=US/postalCode=15203/ST=Pennsylvania/L=Pittsburgh/street=Sui
+te 510/street=2403 Sidney Street/O=pair Networks, Inc./OU=Provided by
+ pair Networks/OU=PairWildcardSSL $250,000/CN=*.pairsite.com

$ openssl s_client -showcerts -servername www.perlmonks.org -connect 6
+6.39.54.27:443 </dev/null 2>&1| grep subject
subject=/CN=perlmonks.org

$ openssl s_client -showcerts -servername www.perlmonks.org -connect 2
+16.92.34.251:443 </dev/null 2>&1| grep subject
subject=/CN=perlmonks.org
[download]

There is more than one way to set up Apache to rewrite and find the cert.

I'm sure the admins will find a stable way.

The short term certificate is surely only meant for testing.