Certbot reverse proxy transparency error

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: torei.stream.raindrop.ink

I ran this command: sudo certbot

It produced this output: Congratulations! You have successfully enabled https://torei.stream.raindrop.ink

My web server is (include version): Apache 2.4.46

The operating system my web server runs on is (include version): Linux ferio.raindrop.works 5.4.0-88-generic #99-Ubuntu SMP Thu Sep 23 17:29:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

My hosting provider, if applicable, is: Self Host

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 0.40.0

Certbot seems to have built the certificate correctly, but I can't open the page. On Chrome, I get the "NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED", and HSTS won't allow me to bypass the error

No errors appear in the apache error log (the last comment was from ten minutes before when it provided the following information from certbot's Acme tests:

[Sun Oct 10 21:17:07.977476 2021] [proxy:error] [pid 375054:tid 139931217282816] (20014)Internal error (specific information not available): [client 66.133.109.36:61142] AH01084: pass request body failed to 127.0.0.1:444 (localhost), referer: http://torei.stream.raindrop.ink/.well-known/acme-challenge/iowUVVPLrT7aTaprIZMpWD6b-7G7wp_Xzmsfldwyxn0
[Sun Oct 10 21:17:07.977588 2021] [proxy:error] [pid 375054:tid 139931217282816] [client 66.133.109.36:61142] AH00898: Error during SSL Handshake with remote server returned by /.well-known/acme-challenge/iowUVVPLrT7aTaprIZMpWD6b-7G7wp_Xzmsfldwyxn0, referer: http://torei.stream.raindrop.ink/.well-known/acme-challenge/iowUVVPLrT7aTaprIZMpWD6b-7G7wp_Xzmsfldwyxn0
[Sun Oct 10 21:17:07.977603 2021] [proxy_http:error] [pid 375054:tid 139931217282816] [client 66.133.109.36:61142] AH01097: pass request body failed to 127.0.0.1:444 (localhost) from 66.133.109.36 (), referer: http://torei.stream.raindrop.ink/.well-known/acme-challenge/iowUVVPLrT7aTaprIZMpWD6b-7G7wp_Xzmsfldwyxn0

The conf file for the particular domain (other configs are working properly for this domain and others)

        ServerName torei.stream.raindrop.ink
        ServerAlias torei.stream.raindrop.ink
        LogLevel warn
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
                ProxyPreserveHost On
                ProxyPass / http://127.0.0.1:90/
                ProxyPassReverse / http://127.0.0.1:90/

RewriteEngine on
RewriteCond %{SERVER_NAME} =torei.stream.raindrop.ink
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<IfModule mod_ssl.c>

<VirtualHost *:443>
        ServerName torei.stream.raindrop.ink
        SSLEngine On
        SSLProxyEngine On
        LogLevel warn
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
                ProxyPreserveHost On
                ProxyPass / https://127.0.0.1:444/
                ProxyPassReverse / https://127.0.0.1:444/

SSLCertificateFile /etc/letsencrypt/live/torei.stream.raindrop.ink/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/torei.stream.raindrop.ink/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

And yes, using port 90 and 444 are working from the local network, so it seems either a cert or a proxy issue

2

Please show the exact command/URL used to confirm:

I show:

curl -Iki https://torei.stream.raindrop.ink
HTTP/2 500
date: Mon, 11 Oct 2021 05:15:15 GMT
server: Apache/2.4.46 (Ubuntu)
content-type: text/html; charset=iso-8859-1

[ERROR 500] Which implies the proxy is unable to reach the provided URL.

3

on another computer in the home network, I can open/navigate around http://192.168.1.103:90 and https://192.168.1.103:444 (after bypassing the certificate warning)

4

May not equal:

On the server, let's have a look at:
sudo netstat -pant | grep 444
curl -Ii https://192.168.1.103:444 | head
curl -Ii https://127.0.0.01:444 | head

5 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.```

```heatheriac@ferio:~$ curl -Ii https://127.0.0.1:444 | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

This seems to suggest a cert conflict, and if I'm right, I -think- I have an idea why. Let me poke around with the docker container it's connecting to and check something

6

Do you need to go securely from the proxy to 192.168.1.103?
[is that the same system?]

What happened with the output of:

7

It is the same system. I have two other dockerized systems that I use a similar reverse proxy with, and this is the only time I've had issues. I'm still looking into the self-signed cert issue on my end, but here's the netstat

tcp        0      0 0.0.0.0:444             0.0.0.0:*               LISTEN      472245/docker-proxy
tcp6       0      0 :::444                  :::*                    LISTEN      472253/docker-proxy
8

If you don't need to be secure between them, then change HTTPS to HTTP.

If you do need to be secure between them, then you may need to put a trusted cert at:
https://127.0.0.1:444

9

So in both the :80 and :443 stanzas of the config file, point them to :444 no matter what?

10

No change the :443 vhost only; the :80 vhost is not having a problem.
:80 goes to :90 (HTTP)
:443 goes to :444 (HTTPS) <<<< switch this to HTTP :90
OR if there is no cert on :444, then (also) HTTP :444 [weird but doable]
OR use :444 (HTTPS) but you have to use a trusted cert there.

11

Okay, took me a minute to realize what you were asking me to do. While I was trying to scrub everything to make sure there was no self-signed certs in the system, I came across another bug that seems to have some documentation with the devs. So it'll probably take me a bit of time to clear that and see if it fixes other things

12

I don't think I spelled it out right - but I think you get the idea.
On the Internet, you have :80 and :443
Between the two systems, you can use HTTP:90 for both [simplest method]

13

It was a bit of a mess, but after a full purge of the docker stack (including all orphaned volumes), -and- your recommendation to point everything to HTTP/90, it -is- loading the site, -and- the cert is loading as 100% valid

THANK YOU SO MUCH!!!!

1 Like
14

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