Makes A Cert But CURL Shows Cert For Main Domain Instead

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:
https://pcnselect.com

I ran this command:
curl -v https://pcnselect.com

It produced this output:

  • Rebuilt URL to: https://pcnselect.com/
  • Trying 2600:3c03::f03c:91ff:feee:4681...
  • TCP_NODELAY set
  • Connected to pcnselect.com (2600:3c03::f03c:91ff:feee:4681) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Unknown (8):
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject: jurisdictionC=US; jurisdictionST=Pennsylvania; businessCategory=Private Organization; serialNumber=692470; C=US; ST=Pennsylvania; L=Camp Hill; O=Pennsylvania Educational Communications Systems; CN=www.pcntv.com
  • start date: Aug 8 12:35:24 2024 GMT
  • expire date: Sep 9 12:35:24 2025 GMT
  • subjectAltName does not match pcnselect.com
  • SSL: no alternative certificate subject name matches target host name 'pcnselect.com'
  • stopped the pause stream!
  • Closing connection 0
  • TLSv1.3 (OUT), TLS Unknown, Unknown (21):
  • TLSv1.3 (OUT), TLS alert, Client hello (1):
    curl: (51) SSL: no alternative certificate subject name matches target host name 'pcnselect.com'

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

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

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):
certbot 4.0.0

-- Main domain has a GoDaddy cert, two ther sites on her are Certbot certs and work fine, new site gets cert no problem, but CURL requests get main domain instead, which is causing all sorts of havoc across the internet.

2

Hello @pcnweb, welcome back! :slight_smile:

Your site has 2 IP Address one IPv4 and one IPv6 which is nice and fine.

Using the one line tool Let's Debug shows that the 2 IP Addresses are not responding the same https://letsdebug.net/pcnselect.com/2423035

Also https://www.ssllabs.com/ssltest/analyze.html?d=pcnselect.com shows

image
image1093×586 33.3 KB

2 Likes
3

Thanks, how do I fix it - it's setup identically (with a different domain name) as all the working domains on this box.

4

Here is another site on the same box with a duplicate (except for the domain) "sites-available" nginx file:

5

With curl put a -4 command line option for force use of IPv4 or -6 for force use of IPv6.
(Mostly for testing to assist in a diagnose.)

2 Likes
6
curl -4 -k -v https://pcnselect.com 
>curl -4 -k -v https://pcnselect.com
* Host pcnselect.com:443 was resolved.
* IPv6: (none)
* IPv4: 45.33.82.169
*   Trying 45.33.82.169:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=pcnselect.com
*  start date: Apr 17 21:10:02 2025 GMT
*  expire date: Jul 16 21:10:01 2025 GMT
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to pcnselect.com (45.33.82.169) port 443
* using HTTP/1.x
> GET / HTTP/1.1
> Host: pcnselect.com
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 17 Apr 2025 23:16:47 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: PHPSESSID=p7hcrq989kkh5mmqotp298vknj; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< X-Powered-By: Scrapple 7.0
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
<
<!DOCTYPE html>
<html lang="en">


<head>
curl -6 -k -v https://pcnselect.com 
>curl -6 -k -v https://pcnselect.com
* Host pcnselect.com:443 was resolved.
* IPv6: 2600:3c03::f03c:91ff:feee:4681
* IPv4: (none)
*   Trying [2600:3c03::f03c:91ff:feee:4681]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: jurisdictionC=US; jurisdictionST=Pennsylvania; businessCategory=Private Organization; serialNumber=692470; C=US; ST=Pennsylvania; L=Camp Hill; O=Pennsylvania Educational Communications Systems; CN=www.pcntv.com
*  start date: Aug  8 12:35:24 2024 GMT
*  expire date: Sep  9 12:35:24 2025 GMT
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify result: self-signed certificate in certificate chain (19), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 3: Public key type RSA (2048/112 Bits/secBits), signed using sha1WithRSAEncryption
* Connected to pcnselect.com (2600:3c03::f03c:91ff:feee:4681) port 443
* using HTTP/1.x
> GET / HTTP/1.1
> Host: pcnselect.com
> User-Agent: curl/8.12.1
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Thu, 17 Apr 2025 23:18:13 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< Expires: Wed, 11 Jan 1984 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private
< X-Redirect-By: WordPress
< Location: https://pcntv.com/
< X-Powered-By: Scrapple 7.0
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
<
* Connection #0 to host pcnselect.com left intact
3 Likes
7

That site only has 1 IP Address, an IPv4 Address.

image
image1087×657 61.5 KB

1 Like
8

You are right, I think I have some NGINX file sites-available file collisions I need to sort out - need to find some current multiple site hosting example files.

1 Like
9

I think you might have faulty listen statements in your nginx server blocks.

Check that you have a listen for each of IPv4 and IPv6 for your pcnselect.com domain. Requests to that domain using IPv6 are handled by pcntv instead. That one probably has an IPv6 listen but if pcnselect does not it will never get chosen by nginx to process those

2 Likes
10

It's weird, Certbot adds:

listen 443 ssl; # managed by Certbot

and in a separate block:

listen 80;

in my conf file, but it doesn;t seem to "get" there - I'm wondering if something in the original "main" conf is messing it up - I just switched it to Certbot from GoDaddy and it has:

listen 80 default_server;
listen [::]:80 default_server;

and in another block:

listen 443 ssl default_server;
listen [::]:443 ssl default_server;

  • I'm wondering if "default_server" needs to changed to the domain names.
11

No. Certbot creates a server block for port 443 if you use certbot --nginx. It bases the listen and other statements on the existing server block for port 80. If port 80 only listened on IPv4 then the new port 443 server block will also be IPv4 only.

Your defaul_server stays the same but you can see it has both IPv4 and v6 listen statements. Generally, every server block (port 80 and 443) should have the same kind of listen statements. You probably had a mix in your original port 80 blocks which is why there is a mix now.

Just manually go through each server block and make sure it has a listen for IPv6

3 Likes