Wrong certificate is being identified in browser

glen4cindy · February 11, 2023, 2:00am

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: newstart.cloudns.ph

I ran this command:

It produced this output:

My web server is (include version): Ubuntu 22.10

The operating system my web server runs on is (include version): Windows Server 2019

My hosting provider, if applicable, is: Mochahost

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): yes

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

I'm attempting to stand up another instance of Bitwarden. Not so I can run 2 of them side by side, but as a way to have a ready to deploy version should there be a sudden unfixable problem with the main one.

At any rate I kept having this same issue with a dynamic DNS host I set up that was similar to my existing one. I thought that was the issue.

So I made a completely different dynamic DNS host with a completely unrelated name.

newstart.cloudns.ph

I used ZeroSSL to obtain an SSL certificate for this host and proceeded to install Bitwarden on this 2nd server the same way I did it the first time.

Everything seems to go as expected until I try to load the page for Bitwarden. Chrome gives the following error: NET::ERR_CERT_COMMON_NAME_INVALID

If I click the padlock Chrome thinks the certificate is: Common Name (CN) bitwarden.glenspcservice.com

That's not the certificate that's installed on the server.

Is my public IP address somehow interfering with this? I don't understand how a completely unrelated host can be seeing another certificate.

Thanks in advance.

MikeMcQ · February 11, 2023, 3:11am

First, they are very much related because both their DNS point to the same IP. So, your web server must handle SNI to allow that to work.

Further, I assume you are using the non-standard port 8443 for HTTPS rather than 443. It would have been helpful had you mentioned that here. Because port 80 and 443 are not accessible to either of these domains I looked at your forum history.

Your response headers say server is nginx but are you able to configure that? Or, is that just the underlying system for bitwarden or some other software you run?

glen4cindy · February 11, 2023, 3:34am

Thanks so much for your response.

I can configure nginx indirectly. There is a config.yml file that generates the nginx.conf files. The nginx folder doesn't have a sites-available/default-ssl.conf.

I have manually copied the certificate files ./bwdata/ssl/newstart.cloudns.ph directory.

I can't figure out the right way to format the certbot command in the run.sh file to do DNS validation.

MikeMcQ · February 11, 2023, 3:38am

What does a DNS challenge have to do with anything? You said you got a cert for your newstart domain already (and I see the ZeroSSL cert in crt.sh too).

You just have to configure your server software to use it.

I really think you need to learn more about your server software. Visit its docs. Visit forums that focus on those products.

glen4cindy · February 11, 2023, 3:53am

I'm sorry for not being more precise. I manually installed the certificate files after I could not figure out how to make the DNS challenge work.

The Bitwarden install is pretty scripted. The certificate process assumes port 80 is open. I'm sorry I wasn't more clear.

Bruce5051 · February 11, 2023, 5:55pm

Using the online tool SSL Checker shows "Doesn't match Common Name or/and SANs" https://decoder.link/sslchecker/newstart.cloudns.ph/8443

Supplemental information:

$ nmap -Pn newstart.cloudns.ph
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-11 17:50 UTC
Nmap scan report for newstart.cloudns.ph (97.88.217.20)
Host is up (0.087s latency).
rDNS record for 97.88.217.20: 097-088-217-020.res.spectrum.com
Not shown: 995 filtered ports
PORT     STATE  SERVICE
443/tcp  closed https
5001/tcp open   commplex-link
5060/tcp open   sip
8000/tcp closed http-alt
8443/tcp open   https-alt

Nmap done: 1 IP address (1 host up) scanned in 10.37 seconds

And the certificate I presently see being served, why are you configuring the server to serve a Certificate for bitwarden.glenspcservice.com instead of a Certificate for newstart.cloudns.ph?

$ openssl s_client -showcerts -servername newstart.cloudns.ph -connect newstart.cloudns.ph:8443 < /dev/null
CONNECTED(00000003)
depth=0 CN = bitwarden.glenspcservice.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = bitwarden.glenspcservice.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = bitwarden.glenspcservice.com
verify return:1
---
Certificate chain
 0 s:CN = bitwarden.glenspcservice.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Dec 18 14:44:58 2022 GMT; NotAfter: Mar 18 14:44:57 2023 GMT
-----BEGIN CERTIFICATE-----
MIIFPzCCBCegAwIBAgISBMYZQ99X63GtFGB3XRyGemH1MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjEyMTgxNDQ0NThaFw0yMzAzMTgxNDQ0NTdaMCcxJTAjBgNVBAMT
HGJpdHdhcmRlbi5nbGVuc3Bjc2VydmljZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDZH4S6iddHqUxlNPWIDn+XFKALxZr9b+aQfiZZQvXTPGi0
qBr8CElv99qXXSar+EoZBOxQd3mfTg9xgLQzwFgNlHox9ExjJ4dsxfVOuuHwm1Ci
RzC3Nu9XzyU1CxGmbPKav235EssuKBSL/jD/pMf4AqciJZ7avKJlgBDuk5cdEy6i
wzUkvVTg9ytZPCWurVvlh+nBC1xSIpYAhRMfW9SfvViZIezvDfVRUEy6hSHky/ef
Mkmd1yAK/9J5oYyT7SBiW/6tv/robcq2BDkyF9pAfHWxFkmoWJSW9xUJ3Bpuk2q2
g2lMnsOS7Ek1klDaAWdOn70PSY40Uf7i1wi/nCBBAgMBAAGjggJYMIICVDAOBgNV
HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1Ud
EwEB/wQCMAAwHQYDVR0OBBYEFHRJfSNT8ReotyqqZm4RFWTfkKXWMB8GA1UdIwQY
MBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEF
BQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8v
cjMuaS5sZW5jci5vcmcvMCcGA1UdEQQgMB6CHGJpdHdhcmRlbi5nbGVuc3Bjc2Vy
dmljZS5jb20wTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEFBgorBgEE
AdZ5AgQCBIH2BIHzAPEAdgB6MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1Lr
UgAAAYUl6ObEAAAEAwBHMEUCIQCqnenDyJ7GX17tv3tlqslDeUqP0hJ/kGMWJkty
R2JmvQIgXcMM/JJBSjsFDCht3+UTrnY6kC22cgw/sOzkpqw4cJgAdwC3Pvsk35xN
unXyOcW6WPRsXfxCz3qfNcSeHQmBJe20mQAAAYUl6ObTAAAEAwBIMEYCIQDn1uGo
rDjOApaq+Ole/0fSi4fLR0Yhl8NsuZO7Np3LQwIhAIyZ6tv5s0Gr0FZQ4TmC/GG5
xHJIJ/9ZWkAA5nI1GuurMA0GCSqGSIb3DQEBCwUAA4IBAQB1S8pgoa+FrzpyS6mW
5EjwK3gAn04v+0Xj+pxY208c11suuVo8PngJfdqzTdt9u87orFY8xHAYRlMc24Ff
wphTezo/4I7ktYJGXU58KCIv7eps4x8g2+rVfA9rcftJAGQUOi68ZhtkL1SWFfrI
IxfriojJKWzZhWiEWJjZnGgHMFPYV3WB5oNZlryeQMM0tebzdlTCR5cx967r2q75
lzL3RQEBME6zuI5N/q6myHvsXDzuciIzCbsrIFVyYMPAe9VHHahakCxkNbpn2p4c
uagHdThnrFZo1f3iRMu0obBu1efStihe6Adj0Fg0/VkwJYiY00PPcHu6fGb3Zviv
NY38
-----END CERTIFICATE-----
---
Server certificate
subject=CN = bitwarden.glenspcservice.com
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1829 bytes and written 414 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: C225E61FA94FBBCD993D17832DA9F3FB5DC446F94DA11510C5575D50CA2216B6
    Session-ID-ctx:
    Master-Key: 1E62756A3AA43E77CF330537D2EBC7B198271164590C2B23DE02184A48CA40B7EBC1667878AC174FD19112B0B46A4B27
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1676137930
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
DONE

glen4cindy · February 11, 2023, 6:24pm

I'm posting this question because I do not understand why the certificate you see being served is what's being served.

The certificate.crt file I have in the directory ./bwdata/ssl/newstart.cloudns.ph is:

According to SSL Certificate Decoder

http://www.sslchecker.com/certdecoder?su=2b0907379f82b1b0bef034aea9a19423

Common name: newstart.cloudns.ph

So I'm confused.

Bruce5051 · February 11, 2023, 6:29pm

Kindly wait to see if there are more knowledgeable Let's Encrypt community volunteers willing to assist.

In the mean time, you can find nginx documentation below
http://nginx.org/en/docs/

rg305 · February 11, 2023, 9:54pm

The answer to which is found in:

Windows will build the chain, that it serves, as it sees fit [not always correctly].
Regardless of what you tell it.

Bruce5051 · February 11, 2023, 10:15pm

This is confusing to me

web server something like nginx, Apache, etc; you stated an Operating System
and you state an Operating System of Windows, yet the paths you show use the forward slash (granted on Windows the backslash is only need for command line operations).

glen4cindy · February 11, 2023, 10:22pm

Maybe I'm answering these questions wrong.

The bare metal server is an HP Proliant DL 380 G6 running Windows Server 2019.

Windows Server is running Hyper-V. I have Ubuntu 22.10 running as one of the VM's on this WS2019 install. Once Ubuntu 22.10 was installed, I installed Bitwarden and the prerequisites.

The server that runs as a part of Bitwarden is nginx.

So maybe I'm using some incorrect terminology when I'm answering the leading questions. It's not intended.

Bruce5051 · February 11, 2023, 10:25pm

Thank you. No problem that the terminology is a bit vague, I am only trying to get the information needed to hopefully help solve the issue.

This information you kindly provided is definitely helpful

Bruce5051 · February 11, 2023, 10:44pm

I've never used Bitwarden, have you seen this https://bitwarden.com/help/certificates/#generate-a-certificate-with-lets-encrypt ?

Bruce5051 · February 11, 2023, 11:10pm

If you desire to use the DNS-01 challenge I suggest using one of DNS providers who easily integrate with Let's Encrypt DNS validation

Remember the goal should be automation of certificate renewal since certificate are only valid 90 days from Let's Encrypt and generally renewed every 60 days.

Bruce5051 · February 11, 2023, 11:27pm

And here is a list of issued certificates for

bitwarden.glenspcservice.com crt.sh | bitwarden.glenspcservice.com they are by Let's Encrypt
newstart.cloudns.ph crt.sh | newstart.cloudns.ph they are by ZeroSSL

glen4cindy · February 12, 2023, 12:23am

This was my first choice. The install process for Bitwarden is automatic. There is a run.sh script that contains the certbot command. Here is the command that runs during setup if you choose to let the Bitwarden setup grab the LE certificate:

        mkdir -p $OUTPUT_DIR/letsencrypt
        docker pull certbot/certbot
        docker run -it --rm --name certbot -p 80:80 -v $OUTPUT_DIR/letsencrypt:/etc/letsencrypt/ certbot/certbot \
            certonly --standalone --noninteractive  --agree-tos --preferred-challenges http \
            --email $EMAIL -d $DOMAIN --logs-dir /etc/letsencrypt/logs

This process assumes port 80 is open. This is why I wanted to reformat this command to use the DNS challenge instead but I was unable to get that to work.

That's why I chose a different certificate provider.

Bruce5051 · February 12, 2023, 7:31pm

@glen4cindy you have 3 components at play here:

Bitwarden
nginx
Certbot

Kindly wait to see if there is anyone who knows configuration all 3.
(you might need to read on configuration of each to work out the solution)

Bruce5051 · February 12, 2023, 8:31pm

So one should be able to adjust the script to do what you desire. So you just need to make the adjustments, based off of configuration documentation for Bitwarden, nginx, and Certbot (all which have document web pages to assist).

system · March 14, 2023, 8:31pm

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