"no certificate subject alternative name matches"

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: kongsberg.stage.webcore.no

I ran this command:

It produced this output:

My web server is (include version): nginx / 1.18.0

The operating system my web server runs on is (include version): Ubuntu 22.04

My hosting provider, if applicable, is: Linode

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.10.0

I have an issue with certificates generated by LE that is bugging me.
I have a setup with several instances of nginx running on same server, each nginx-instance has its own LE-generated certificate.
If I access any site in browser from outside of server, all is fine, http/https no problem.
But, if I try to do "wget https://kongsberg.stage.webcore.no" from terminal on the server where this domain is running, I get:

ERROR: no certificate subject alternative name matches

If I access any nginx-instance with a purchased certificate, all is well, no probs.
What is going on, and how can I get around this?
I need this to work with plugins in WordPress that ultimately uses curl.

1 Like
2

Welcome @mronseth

It seems odd that a purchased cert would behave differently. But, let us see what cert wget is getting. Maybe that will help determine what is wrong

Show output of this command. I know it is not exactly like wget but probably will help

echo | openssl s_client -connect kongsberg.stage.webcore.no:443 | head
3 Likes
3

Hello @mronseth, welcome to the Let's Encrypt community. :slightly_smiling_face:

I am guessing the problem is with www.kongsberg.stage.webcore.no as the presently being served certificate shown here https://decoder.link/sslchecker/www.kongsberg.stage.webcore.no/443 does not cover that domain name. And that is this certificate crt.sh | 13287567611

Yet kongsberg.stage.webcore.no has its domain name covered as shown here https://decoder.link/sslchecker/kongsberg.stage.webcore.no/443
which is this certificate crt.sh | 13295080287
and it only covers that 1 Domain Name.

Here is a list of issued certificates crt.sh | kongsberg.stage.webcore.no

3 Likes
4

Good guess. The purchased cert probably automatically included the www subdomain.

4 Likes
5

Hi!

Output is as shown - checks against a certificate for another nginx instance running on the same server. I thought SNI would resolve to certificate for kongsberg.stage.webcore.no, but rather it yields static.webcore.no...

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = static.webcore.no
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = static.webcore.no
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Apr 11 05:43:41 2024 GMT; NotAfter: Jul 10 05:43:40 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
DONE
1 Like
6

Well, once a request arrived at one of your nginx instances then SNI (or just HOST matching for HTTP) would apply.

But, what do you have that routes the requests to a specific nginx instance? How does it handle HTTPS requests? Sounds like something is getting lost from your request to the one nginx you want.

2 Likes
7

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