Site can't provide a secure connection

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: workshop.glenspcservice.com

I ran this command: certbot -d workshop.glenspcservice.com --manual --preferred-challenges dns certonly

It produced this output: I didn't save the output

My web server is (include version):

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

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

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

My ISP blocks port 80. When I ran certbot on my server I had to use DNS validation. Certbot returned with directions to add this long string of characters I had to add to my DNS records on my site. I did this and DNS validation was successful.

Running "certbot certificates" returns the following:

Found the following certs:
Certificate Name: workshop.glenspcservice.com
Serial Number: 35dd856a4cb6ae24763fcd98be3873cc949
Key Type: RSA
Domains: workshop.glenspcservice.com
Expiry Date: 2023-04-28 13:55:22+00:00 (VALID: 88 days)
Certificate Path: /etc/letsencrypt/live/workshop.glenspcservice.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/workshop.glenspcservice.com/privkey.pem

I'm able to see the certificate by looking at my cPanel as well and these match.

When I point my browser to https://workshop.glenspcservice.com:3000 (3000 is the port the service I'm running uses) I get the message "This site can't provide a secure connection."

I've tried the Let's Debug test and the "well known acme challenge" string of characters changes every time. I'm not sure if this is the way it works because I know I changed the record that was there before when I ran certbot and it gave me the record to replace.

97.88.217.20: Fetching http://workshop.glenspcservice.com/.well-known/acme-challenge/13itkx7g7shocANDH8t6RSCqb5nG0l_QaK5F0PoPiIc: Timeout during connect (likely firewall problem.)

Is there something I'm missing here?

Thanks in advance.

2

This is to be expected with your following statement in mind:

That's because that port 3000 is an HTTP port and is not HTTPS. You've ran Certbot with the certonly command, which means you're responsible for installing the certificate into the appropriate services yourself.

4 Likes
3

I need help understanding "installing the certificate into the appropriate services yourself."

When I look at the following:

/etc/letsencrypt/live/workshop.glenspcservice.com/fullchain.pem
/etc/letsencrypt/live/workshop.glenspcservice.com/privkey.pem

The certificate is there.

What step did I miss? Can you point me in the right direction?

Thanks in advance

1 Like
4

Yup. The certificate (and private key) is there. It's just sitting there, being files on a filesystem. Nothing more, nothing less. Files can be used by programs, but those programs need to be told on how to use those files. Programs/services won't magically know to use those files, unless instructed to.

You have a HTTP service running on port 3000. I have no idea what that service is, as it does not provide a Server HTTP header. You should look in the documentation of that service and see how you can install a TLS certificate to enable HTTPS.

Hm, it looks like your service is "Standard Notes", whatever that may be. See Securing HTTP traffic of your server for more info about how to secure Standard Notes.

4 Likes
5

You are using the HTTP-01 Challenge which require Port 80

Best Practice - Keep Port 80 Open

Let's Debug for HTTP-01 shows https://letsdebug.net/workshop.glenspcservice.com/1354301

workshop.glenspcservice.com has an A (IPv4) record (97.88.217.20)
but a request to this address over port 80 did not succeed. Your web server
must have at least one working IPv4 or IPv6 address.

And here is a list of issued certificates crt.sh | workshop.glenspcservice.com, the latest being 2023-01-28.

So like @Osiris said

So you just need to configure (possibly copy/move) the web server and serve the certificate.

6

Somehow the certbot request isn't trying the directed DNS choice.
Try changing the order:
certbot certonly --manual --preferred-challenges dns -d workshop.glenspcservice.com

2 Likes
7

Supplemental information:

$ nmap -Pn workshop.glenspcservice.com
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2023-01-29 12:10 PST
Nmap scan report for workshop.glenspcservice.com (97.88.217.20)
Host is up (0.086s 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
3000/tcp open   ppp
5001/tcp open   commplex-link
5060/tcp open   sip
8443/tcp open   https-alt

Nmap done: 1 IP address (1 host up) scanned in 8.23 seconds
1 Like
8

I'm not sure if that's relevant any longer, OP clearly has a perfectly fine certificate which is valid for another 88 days. I think the timeout error is a red herring and OP should focus on installing the cert into whichever server they have running on that port 3000. (And I already pointed out a guide for that "Standard Notes" service above.)

3 Likes
9

I configured my reverse proxy using the instructions provided:

But this brings up a couple of questions. Some of the other configurations I've seen specify the SSL certificate path on the listen port. In the example I looked at:

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

I noticed the standardnotes.conf file example in the instructions there is no reference to the path to the certificate files.

My other concern is the first line that says:

server {
  listen 80;

Since port 80 is blocked by my ISP, will any traffic ever reach the reverse proxy?

Thanks for all the input so far.

2 Likes
10

You shouldn't be listening to more than one port per vhost.
It is either for HTTP OR for HTTPS [not both].

3 Likes
11

Yes, and no.
I do see how it makes sense given the topic title [and provided information].
But it will become relevant as time passes and a renewal is required.
Without the proper syntax no such renewal can occur.

2 Likes
12

The certificate is installed on the server in these locations.

/etc/letsencrypt/live/workshop.glenspcservice.com/fullchain.pem
/etc/letsencrypt/live/workshop.glenspcservice.com/privkey.pem

Maybe there's a config file issue that needs to tell the server where to find them?

13

I'm pretty sure OP is just confusing you by mixing multiple outputs of multiple Certbot runs :wink:

Depends which URL is used and which browser. Nginx listening on port 80 won't do you any good, but if your ISP does allow port 443 and users are using Chrome, they'll by default go to your HTTPS website before trying HTTP on port 80.

You can follow that port of the guide without a problem, but it won't actually do you any good.

Also note that their reference to Certbot will lead you down the standard path of getting a certificate using the http-01 challenge. But you already have a certificate, so once nginx is configured on port 80, you want to use the certbot install --nginx command to install the already existing certificate into nginx.

Note that this is pretty much basic webserver stuff. You might want to read some more guides on nginx to familiarise yourself with it more.

3 Likes
14

As they have done to themselves...

Yes.
All programs that use certs have to be told where to find their cert files.
But that is not a job for certbot [not without some sort of request to do so - like: --nginx or --apache].

3 Likes
15

I ran certbot install --nginx command:

Successfully deployed certificate for workshop.glenspcservice.com to /etc/nginx/sites-enabled/standardnotes.conf

This is part of what has been added to the conf file:

location / {
proxy_pass http://127.0.0.1:3000;
}

listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/workshop.glenspcservice.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/workshop.glenspcservice.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

I see port 3000 referenced in proxy pass. I'm self hosting Bitwarden and had to use port 8443 because of port 443 being blocked by my ISP.

I tested nginx config:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

I keep saying thanks and I do mean it. I'm just not sure what else is missing here.

Thanks again.

1 Like
16

Supplemental information

$ curl -Ii http://workshop.glenspcservice.com:3000/
HTTP/1.1 200 OK
X-API-Gateway-Version: local
Content-Security-Policy: default-src https: 'self';base-uri 'self';child-src * blob:;connect-src *;font-src * 'self';form-action 'self';frame-ancestors * *.standardnotes.org *.standardnotes.com;frame-src * blob:;img-src 'self' * data:;manifest-src 'self';media-src 'self';object-src 'self';script-src 'self';style-src 'self';script-src-attr 'none';upgrade-insecure-requests
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
Origin-Agent-Cluster: ?1
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
X-XSS-Protection: 0
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 199
ETag: W/"c7-9b0zOo4vDak243r+Gn0Nsqpo8lI"
Date: Sun, 29 Jan 2023 21:50:46 GMT
Connection: keep-alive
Keep-Alive: timeout=5

$ curl -Ii https://workshop.glenspcservice.com:3000/
curl: (35) error:0A00010B:SSL routines::wrong version number

$ curl -k -Ii https://workshop.glenspcservice.com:3000/
curl: (35) error:0A00010B:SSL routines::wrong version number

And https://decoder.link/sslchecker/workshop.glenspcservice.com/3000

1 Like
17

Certbot will put HTTPS on port 443.

You might wanted to tell us that earlier too...

You can change port 443 in nginx to any other port not yet used.

4 Likes
18

Supplemental information present nmap -Pn workshop.glenspcservice.com from my location

$ nmap -Pn workshop.glenspcservice.com
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2023-01-29 13:58 PST
Nmap scan report for workshop.glenspcservice.com (97.88.217.20)
Host is up (0.088s 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
3000/tcp open   ppp
5001/tcp open   commplex-link
5060/tcp open   sip
8443/tcp open   https-alt

Nmap done: 1 IP address (1 host up) scanned in 9.75 seconds
1 Like
19

Supplemental Port 3000 and Port 8443 curl
https://decoder.link/sslchecker/workshop.glenspcservice.com/8443

$ curl -Ii http://workshop.glenspcservice.com:3000/
HTTP/1.1 200 OK
X-API-Gateway-Version: local
Content-Security-Policy: default-src https: 'self';base-uri 'self';child-src * blob:;connect-src *;font-src * 'self';form-action 'self';frame-ancestors * *.standardnotes.org *.standardnotes.com;frame-src * blob:;img-src 'self' * data:;manifest-src 'self';media-src 'self';object-src 'self';script-src 'self';style-src 'self';script-src-attr 'none';upgrade-insecure-requests
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
X-Content-Type-Options: nosniff
Origin-Agent-Cluster: ?1
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
X-XSS-Protection: 0
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 199
ETag: W/"c7-9b0zOo4vDak243r+Gn0Nsqpo8lI"
Date: Sun, 29 Jan 2023 21:59:53 GMT
Connection: keep-alive
Keep-Alive: timeout=5

$ curl -k -Ii https://workshop.glenspcservice.com:8443/
HTTP/2 200
server: nginx
date: Sun, 29 Jan 2023 21:59:58 GMT
content-type: text/html
content-length: 1238
vary: Accept-Encoding
accept-ranges: bytes
etag: "1d9220166412b56"
last-modified: Fri, 06 Jan 2023 19:02:19 GMT
strict-transport-security: max-age=15768000
referrer-policy: same-origin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com; child-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-src 'self' https://*.duosecurity.com https://*.duofederal.com; connect-src 'self' wss://bitwarden.glenspcservice.com https://api.pwnedpasswords.com https://2fa.directory; object-src 'self' blob:;
x-frame-options: SAMEORIGIN
x-robots-tag: noindex, nofollow
1 Like
20

Supplemental Certificate being served on Port 8443

$ openssl s_client -showcerts -servername workshop.glenspcservice.com -connect workshop.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 422 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: 67492095A5429A792206A288D031396820B7CAA4192C285765299CDC9D6B2925
    Session-ID-ctx:
    Master-Key: C28B4E46C3C20A0D50F18360787687FBD006F6B99A7094FD4936343B5C00E852BF1DA644FC54ACA585234322C8A5A5B1
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1675029763
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---
DONE

This issued certificate crt.sh | 8236700241

1 Like