Browser is loading wrong certificate

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://www.myhomelab.glenspcservice.com/

I ran this command: sudo certbot certonly -v --manual --preferred-challenges dns

It produced this output: Please deploy a DNS TXT record under the name:

_acme-challenge.myhomelab.glenspcservice.com

with the following value:

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): 102.0 (build 28)

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

I've configured another Bitwarden server for a couple of reasons. I want a backup in case my primary machine goes down. I want to know I can do it again.

I'm stuck and I've been able to get great help here before so here I am.
I reached out to Mochahost first and they acted like they had no part of this. The subdomain I'm using is through them but they say this issue isn't theirs.

I successfully obtained a certificate with the certbot command I issued. I then copied the pem files to the appropriate file locations.

When I started the Bitwarden server and loaded the webpage I got an insecure page warning. When I clicked on the triangle it indicated the certificate for bitwarden.glenspcservice.com which is my other server.

I wanted to make certain the certificate was correct so I checked the certificate that was loaded on the Bitwarden server. I cut and pasted it into a certificate decoder and it was decoded properly as: myhomelab.glenspcservice.com.

After being put off by Mochahost I went directly to the SSL/TLS section of my cPanel and copied ca.crt, certificate.crt, and private.key directly from myhomelab.glenspcservice.com and placed them into the appropriate files of the bitwarden server.

Even after doing this https://myhomelab.glenspcservice.com:8443 still causes a privacy error and clicking on the triangle:

It's loading this certificate: Common Name (CN)

bitwarden.glenspcservice.com

Any help resolving this would be appreciated.

2

It sounds like a slightly complex setup but basically if the wrong cert is being returned by the server then either:

  • the wrong webserver is responding on that hostname (I assume port 8443 is being forwarded to the correct server internally)
  • your webserver (nginx) config is pointing to the wrong certificate files
  • or the cert files themselves are the wrong ones
  • or the webserver is not configured to use SNI (server name) in the webserver bindings config. This may result in the first cert being returned that matches the config if there is not a more specific config defined.
3 Likes
3

This is what I have found for the certificate being served

for www.myhomelab.glenspcservice.com:443

https://www.ssllabs.com/ssltest/analyze.html?d=www.myhomelab.glenspcservice.com&latest
note the second certificate as well

image
image1002×225 1.76 KB 

$ openssl s_client -showcerts -servername www.myhomelab.glenspcservice.com -connect www.myhomelab.glenspcservice.com:443 < /dev/null
CONNECTED(00000003)
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 = myhomelab.glenspcservice.com
verify return:1
---
Certificate chain
 0 s:CN = myhomelab.glenspcservice.com
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb 17 23:15:28 2023 GMT; NotAfter: May 18 23:15:27 2023 GMT
-----BEGIN CERTIFICATE-----
MIIFXzCCBEegAwIBAgISBNAoAB1iLOQjcJpw8n9AUOdNMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzAyMTcyMzE1MjhaFw0yMzA1MTgyMzE1MjdaMCcxJTAjBgNVBAMT
HG15aG9tZWxhYi5nbGVuc3Bjc2VydmljZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDATpB5bBjiYNAX6Lwzk3CHShSvc5O+2Wi9QPkREHcNUggO
JQTqEGZwl4kgSW8IqKoO12+2PCRjUhWtxT7sdTv8numMWVfHVHZPMUqBbA8uNemx
XZz4EM5jPr0e53IrPJZtjZytub9N9cTIDQEmX+AHI2i/+lVAagLvZOs9Lo0Z+MCs
0Zs6Flttw64jZ7rInrz9+EmmPKjevhltX0R/g+eBS1lA5DorGZvhKK3pONkTiX9s
+W3/tAlLsN5C61gqZnm5t+RQ5i6JQypuXGAqxAbYC3H5aujmvT5wurrYR0PZdpV3
GDiWMk2+SETWmVqybHC0qcRltRW0UB4PHO934DLHAgMBAAGjggJ4MIICdDAOBgNV
HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1Ud
EwEB/wQCMAAwHQYDVR0OBBYEFN/eZsE+bGSSmcH6x9WX6E6Efz/PMB8GA1UdIwQY
MBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggrBgEF
BQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRwOi8v
cjMuaS5sZW5jci5vcmcvMEkGA1UdEQRCMECCHG15aG9tZWxhYi5nbGVuc3Bjc2Vy
dmljZS5jb22CIHd3dy5teWhvbWVsYWIuZ2xlbnNwY3NlcnZpY2UuY29tMEwGA1Ud
IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0
dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBAwYKKwYBBAHWeQIEAgSB9ASB8QDv
AHUAejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61IAAAGGYeAyYwAABAMA
RjBEAiBJsKLTmClJVq8UM5AmvV5P+1cxq0YIabmNdSoBHaT6lwIgQ0PsMNxCKqsp
s3gzNSjpZYBhzCwpLoaraf2ZU5Qr+mkAdgDoPtDaPvUGNTLnVyi8iWvJA9PL0RFr
7Otp4Xd9bQa9bgAAAYZh4DJHAAAEAwBHMEUCIHGwnwhl/XCiP542fMQcmrwfw7zy
SLEOhvG0FBalKl2RAiEA5eUPpszqzauuzJBs+9FndvmwQkt+s2SdtzKY0nsrDCcw
DQYJKoZIhvcNAQELBQADggEBADltlFLd1/ykEpVaO8UWfW5C+Ff/c6ZN2W3wc79h
/GWSLystKMmT8eqv3jxvZKGvQLs8h3/ECpkKNE+67L8UP5RgpR584rBqF5yNkx/m
mHjAA3New6Fj4WBAgdJBTf6ozh83z9kJf94wPOUtss/kHKyC+CA2HWNc8DVyIIYg
GWseDPyZiaLpy/MelEIVOHZJSGWG6ju40+T4WUdjBEg3MRA13rW9SgtZW2lL8vvc
md600MXL0RVYBz3FZixeSvVqqlRnmPWXcc3jV/lJVaGZOpZNCNwecnLCXfaN2j54
acKCiQpq4LjcSSa+vT6fnNCL3WfjD5M72nRDy3SpNqcm5cA=
-----END CERTIFICATE-----
 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
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
---
Server certificate
subject=CN = myhomelab.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 3381 bytes and written 427 bytes
Verification: OK
---
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: 0C5DB81BEA999927D8308D0CA97AC87BCC6CF91ED4680047C2401ED757874C91
    Session-ID-ctx:
    Master-Key: 207DCCC2743F6AA6CF9D7CED64046B04BE557BA3BD12119B2C9C2643735A4FBE4FBD18B99EC5DD35E69E1C2502591290
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 24 a6 ef 11 ed 90 ff 33-73 5b 21 c9 54 0b 86 18   $......3s[!.T...
    0010 - 16 88 77 90 37 17 e4 87-b1 87 99 da 8b 5c 28 69   ..w.7........\(i
    0020 - 62 5b 12 7b 19 e8 9a 04-16 55 ce 2e 97 45 d0 53   b[.{.....U...E.S
    0030 - 58 34 aa ed 90 47 e5 d2-1d b8 86 58 d9 9f bf 61   X4...G.....X...a
    0040 - 08 4f ca 36 ce 27 e6 a0-e7 f5 e3 a4 6e a4 71 4f   .O.6.'......n.qO
    0050 - eb bf 97 cc ea 18 51 bf-09 47 0d 2f 3b 03 af eb   ......Q..G./;...
    0060 - 96 f0 fc 0f 41 41 0c 6e-14 19 7f 17 54 32 c8 29   ....AA.n....T2.)
    0070 - 0a ec fa 86 2e 65 9c 40-62 7c ef fe 63 e2 c8 b5   .....e.@b|..c...
    0080 - c5 74 09 9b 3f f4 a0 f9-f6 02 99 d4 53 1e 92 a0   .t..?.......S...
    0090 - 0c 3c b3 08 72 40 2b 07-61 8d d2 cf 7d fa 16 f6   .<..r@+.a...}...
    00a0 - 98 c7 96 e6 dc e4 67 37-1b 10 da bc 10 1e 9c d4   ......g7........
    00b0 - 07 e8 cf 8e e9 1c 95 ac-73 7b 9d dd ab 7b 0f 7c   ........s{...{.|
    00c0 - f6 b7 d6 a4 b6 4e cd 51-19 7e cf f9 d6 26 92 ba   .....N.Q.~...&..
    00d0 - af 40 0b c5 f8 27 2d 81-2a 01 1d 66 fa 54 d2 95   .@...'-.*..f.T..

    Start Time: 1677078306
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
DONE

for myhomelab.glenspcservice.com:8443

$ openssl s_client -showcerts -servername myhomelab.glenspcservice.com -connect myhomelab.glenspcservice.com: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 423 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: CFAC5EA9E144EB614583BB22510E76330111017D080217C3636ADFDF904C34EF
    Session-ID-ctx:
    Master-Key: F30CE322450589D40633737A087BB208FE0C9580643B48D8EEDFFC5EE08467F9576A30DC0C996B6BD974C8BF553D708E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1677079477
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
DONE
1 Like
4

And from https://unboundtest.com/ with results here: https://unboundtest.com/m/TXT/_acme-challenge.myhomelab.glenspcservice.com/LZY6UACG

Query results for TXT _acme-challenge.myhomelab.glenspcservice.com

Response:
;; opcode: QUERY, status: NOERROR, id: 50249
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_acme-challenge.myhomelab.glenspcservice.com.	IN	 TXT

;; ANSWER SECTION:
_acme-challenge.myhomelab.glenspcservice.com.	0	IN	TXT	"yRZdB9tdwOjnyOszLSu6AaEZFRZZAUWFcoZOWIa5o9U"

----- Unbound logs -----
Feb 22 16:05:41 unbound[407294:0] notice: init module 0: validator
Feb 22 16:05:41 unbound[407294:0] notice: init module 1: iterator
Feb 22 16:05:41 unbound[407294:0] info: start of service (unbound 1.16.3).```
2 Likes
5

I'm confused by what's going on here.

You posted a 2nd block with the bitwarden.glenspcservice.com returned by the openssl tool.

The first two also showed blocks, the first of which was the myhomelab.glenspcservice.com.

Part of the confusion comes from the config file. I have the port set to 4443. My original BW server is set to 8443. I wasn't certain if they could both run at the same time using 8443 on different IP addresses so I chose 4443, however it seems like it wants 8443 anyway. I'm not sure if 8443 is hardcoded somewhere or what.

The certificate files are located at ~./bwdata/ssl/myhomelab.glenspcservice.com.

There are 3 files in that directory. ca.crt; certificate.crt; and private.key.

Nowhere on the server do I have any of the certificate files for bitwarden.glenspcservice.com. Those files are on the other BW server which on running on different physical hardware in a VM so there's no way this one can be pulling files from the other one.

Mentions have been made about SNI but I'm not sure how to look for this.

I appreciate the feedback so far.

I saw the answer from webprofusion

6 
$ nmap -Pn www.myhomelab.glenspcservice.com
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-22 16:52 UTC
Nmap scan report for www.myhomelab.glenspcservice.com (204.93.169.73)
Host is up (0.065s latency).
rDNS record for 204.93.169.73: mocha3032-web.mochahost.com
Not shown: 955 filtered ports, 31 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
587/tcp  open  submission
993/tcp  open  imaps
995/tcp  open  pop3s
2525/tcp open  ms-v-worlds
3306/tcp open  mysql
3690/tcp open  svn
8888/tcp open  sun-answerbook

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

Note worthy Other addresses for myhomelab.glenspcservice.com (not scanned): 97.88.217.20

$ nmap -Pn myhomelab.glenspcservice.com
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-22 16:53 UTC
Nmap scan report for myhomelab.glenspcservice.com (204.93.169.73)
Host is up (0.064s latency).
Other addresses for myhomelab.glenspcservice.com (not scanned): 97.88.217.20
rDNS record for 204.93.169.73: mocha3032-web.mochahost.com
Not shown: 955 filtered ports, 31 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
587/tcp  open  submission
993/tcp  open  imaps
995/tcp  open  pop3s
2525/tcp open  ms-v-worlds
3306/tcp open  mysql
3690/tcp open  svn
8888/tcp open  sun-answerbook

Nmap done: 1 IP address (1 host up) scanned in 3.97 seconds
1 Like
7

I think we need a clear picture of your environment from here: Wrong certificate is being identified in browser - #11 by glen4cindy including FQDN & IP Addresses and Port numbers for each piece and all the pieces (both physical and virtual); what certificate you expect to be served for each as well.

3 Likes
8

I don't follow all the pieces but why do you have 2 IP's in your DNS for myhomelab

nslookup myhomelab.glenspcservice.com
Address: 204.93.169.73
Address: 97.88.217.20
5 Likes
9

And they have different ports open, why?

$ nmap -Pn 204.93.169.73
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-22 17:19 UTC
Nmap scan report for mocha3032-web.mochahost.com (204.93.169.73)
Host is up (0.066s latency).
Not shown: 955 filtered ports, 31 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
443/tcp  open  https
465/tcp  open  smtps
587/tcp  open  submission
993/tcp  open  imaps
995/tcp  open  pop3s
2525/tcp open  ms-v-worlds
3306/tcp open  mysql
3690/tcp open  svn
8888/tcp open  sun-answerbook

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

$ nmap -Pn 97.88.217.20
Starting Nmap 7.80 ( https://nmap.org ) at 2023-02-22 17:19 UTC
Nmap scan report for 097-088-217-020.res.spectrum.com (97.88.217.20)
Host is up (0.086s latency).
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 9.96 seconds
2 Likes
10

The first IP address is that of my hosting provider.

myhomelab.glenspcservice.com is a subdomain there.

11

The 2nd IP address here is my public IP.

The closed ports are complements of Spectrum.

12

@glen4cindy And can you share the details requested in Post #7?

1 Like
13

The DNS should point to the public IP that leads to your server.

As it is, when someone asks the DNS for your myhomelab domain they should only get a selection of IP's if they all point to the same place (like a load balancer or other fancy setup).

The first step is fixing the DNS

5 Likes
14

I have this A record set at the hosting provider:

myhomelab.glenspcservice.com. 14400 A
97.88.217.20

I also have port forwarding set on my home router.

I'll post this information when I get home this afternoon and can get access to my server. I do not have remote access here at work.

2 Likes
15

What port do you want to use with myhomelab? 8443?

Because 8443 looks to be forwarded to your bitwarden

3 Likes
16

bitwardeon or not i think he needs a reverse proxy in front of those and proxy should foward by name to containers or something

5 Likes
17

I was thinking the use of such ports as 8443 was to overcome the single external IP to multiple internal web services.
But... if they are all going to use that same port [8443], then we're right back where we started: A single external IP:port and multiple internal web server destinations.
To which:

Is likely the only long-term solution.

5 Likes
18

Here are my config's from both servers.

default.conf from nginx - generated by config.yml

server {
listen 8080 default_server;
listen [::]:8080 default_server;
server_name myhomelab.glenspcservice.com;

return 301 https://myhomelab.glenspcservice.com$request_uri;
}

server {
listen 8443 ssl http2;
listen [::]:4443 ssl http2;
server_name myhomelab.glenspcservice.com;

config.yml

*# Docker compose file port mapping for HTTP. Leave empty to remove the port mapping.*
*# Learn more: https://docs.docker.com/compose/compose-file/#ports*
http_port: 8080
*#*
*# Docker compose file port mapping for HTTPS. Leave empty to remove the port mapping.*
*# Learn more: https://docs.docker.com/compose/compose-file/#ports*
https_port: 4443

default.conf from nginx - generated by config.yml

server {
listen 8080 default_server;
listen [::]:8080 default_server;
server_name bitwarden.glenspcservice.com;

return 301 https://bitwarden.glenspcservice.com$request_uri;

}
server {
listen 8443 ssl http2;
listen [::]:8443 ssl http2;
server_name bitwarden.glenspcservice.com;

*# Docker compose file port mapping for HTTP. Leave empty to remove the port mapping.*
*# Learn more: https://docs.docker.com/compose/compose-file/#ports*
http_port: 8080
*#
*# Docker compose file port mapping for HTTPS. Leave empty to remove the port mapping.*
*# Learn more: https://docs.docker.com/compose/compose-file/#ports*
https_port: 8443

According to the guide you should be able to use ports other than 80/443 by specifying those in config.yml but as is obvious in my examples above I did. 8443 for bitwarden........and 4443 for myhomelab......
Something inside of a configuration file within Bitwarden must be forcing 8443 somewhere. Otherwise, where did this come from?

  listen 8443 ssl http2;
  listen [::]:4443 ssl http2

I would very much like to use a reverse proxy. That's actually the plan with this 2nd instance. The first instance is up, running, and working without any problems. I really don't want to mess with anything that might change this. My plan was to get the 2nd instance up and then get the reverse proxy working. At that point, I would feel confident enough to add a reverse proxy configuration to the other instance of Bitwarden.

Hopefully this makes sense.

1 Like
19

That seems like a mismatch.
Or did you intentionally use a different port for IPv4 than IPv6?
OR did Bitwarden actually make that change for you?

3 Likes
20

This is part of nginx.conf and at the top of this conf file is this notice:

######################################################################
# WARNING: This file is generated. Do not make changes to this file.  #
# They will be overwritten on update. You can manage various settings #
# used in this file from the ./bwdata/config.yml file for your        #
# installation.                                                       #
#######################################################################

The only place in config.yml in this file for port configuration are these lines:

*# Docker compose file port mapping for HTTPS
&
*# Docker compose file port mapping for HTTP

For this instance, I have 4443 as the only port mentioned. I have no idea where 8443 came from unless it is hard coded somewhere in another conf file that isn't one that I configure.

1 Like