Ssl ddns.net apache - debian

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:
rpiben.ddns.net
I ran this command:
$sudo certbot --apache
everything looking ok

Your existing certificate has been successfully renewed, and the new certificate
has been installed.
The new certificate covers the following domains: https://rpiben.ddns.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES:
 - Congratulations! 
   Your certificate and chain have been saved at:
   /etc/letsencrypt/live/rpiben.ddns.net/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/rpiben.ddns.net/privkey.pem

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=rpiben.ddns.net
It produced this output:

Certificate name mismatch  - We were able to retrieve a certificate for this site, but the domain names listed in it do not match the domain name you requested us to inspect

My web server is (include version):
apache 2.48
The operating system my web server runs on is (include version):
Debian10
My hosting provider, if applicable, is:
Noip ddns.net
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):

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

Hello,
I have a python app (piapp.py) sending a basic "hello world' message via WSGI (piapp.wsgi) to the apache server to test the installation.
After running ok certbot, my /etc/apache2/sites-available/piapp.conf file looks like this

----
WSGIApplicationGroup &{GLOBAL}
WSGIProcessGroup piapp
WSGIDaemonProcess piapp user=pi group=www-data threads=5

<VirtualHost *:80>
        ServerName rpiben.ddns.net
	WSGIScriptAlias /piapp /var/www/piapp/piapp.wsgi
	<Directory /var/www/piapp>
		Require all granted
	</Directory>
        RewriteEngine on
        RewriteCond %{SERVER_NAME} =rpiben.ddns.net
        RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

<VirtualHost *:443>
        ServerName rpiben.ddns.net   
        WSGIScriptAlias /piapp /var/www/piapp/piapp.wsgi
        <Directory /var/www/piapp>
                Require all granted
        </Directory>
	SSLEngine on
	SSLCertificateFile /etc/letsencrypt/live/rpiben.ddns.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/rpiben.ddns.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

Access locally via the server IP address 192.168.1.34/piapp working ok
Access from internet (e.g. Android GSM)
https://rpiben.ddns.net/piapp not ok (see message below)
http://rpiben.ddns.net/piapp used to be ok but since I renewed the certificate with redirect from http to https it does not work anymore

NET::ERR_CERT_AUTHORITY_INVALID

Any help much appreciated.

Benoit.

1 Like

Hi @BenoitG, and welcome to the LE community forum :slight_smile:

As with all things Apache on this forum, I would start with the output of:

sudo apachectl -t -D DUMP_VHOSTS

From my perspective, there is clearly some other secure vhost that is conflicting with the one shown.

2 Likes

Welcome @BenoitG

Connections using HTTPS get this response (using -k to temporarily ignore cert failure). Is this some sort of firewall or router? This is the device that needs a proper cert. Or, for HTTPS to go directly to your Apache server

Note the "Server" and "Location" especially

curl -Ik  https://rpiben.ddns.net
HTTP/1.1 307 Temporary Redirect
Location: /7..1./gui/
Date: Sat, 20 Jan 2024 15:42:06 GMT
Server: HTTP Server

An HTTP request gets the normal Apache response

curl -I http://rpiben.ddns.net
HTTP/1.1 301 Moved Permanently
Server: Apache/2.4.38 (Raspbian)
Location: https://rpiben.ddns.net/
2 Likes

@MikeMcQ, has hit this nail on the head:


HTTPS is not reaching your Pi :frowning:

2 Likes

Hi @rg305,
Thank you for the email.

This is the response to the suggested command
$ sudo apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 rpiben.ddns.net (/etc/apache2/sites-enabled/piapp.conf:6)
*:443 rpiben.ddns.net (/etc/apache2/sites-enabled/piapp.conf:17)

Attached are the information ref the port authorization from the network. I'll forward the screenshots of the port mapping in the router and remote access 443 enabled in other mail (As new user I can only send one attachment at a time)

Hope this helps.

Cheers,

Benoit

1 Like

The port mapping in my router

And the port 443 enabled in the router

image
That is conflicting.
Can you change that to some other [unused] port?

Cheers from Miami :beers:

2 Likes

I did enable https to port 8443...
No progress, same error message

Cheers from Belgium - Nivelles
We had 10 cm of snow, -6°C, last couple of days...

Benoit

1 Like

I agree. HTTPS requests on port 443 are still reaching your Proximus router and not Apache.

Do you have to restart the router after that change? If so, did you? You might try it anyway with it set to 8443 :slight_smile:

You could also try disabling HTTPS Remote Access if restarting that device does not help. This setting is not to enable HTTPS in general. It is to support you being able to access its admin panel using HTTPS. You can't have your admin panel using the same port as normal HTTPS requests. That's why there is a conflict.

2 Likes

Also, it is a real security concern that your routers' admin panel can be accessed from the Internet.

3 Likes

Hi,
I have disabled the remote https access, changes are supposed to be done without resetting the router, but same error.
I'll reboot the router tonight.
Thanks.

2 Likes

Hi,
Same error after disabling the https remote access and re-booting the router.

As suggested when running certbot, I did the SSL test via SSLlabs
SSL Server Test: rpiben.ddns.net (Powered by Qualys SSL Labs).
Site not trusted. It reports a self-signed key certificate and not the one generated by cerbot.
See attachment .
Any clue why this is happening?
Thank a lot.
Benoit.

The router refuses to let go of port 443.
You have some choices:

  • get a new/different router [that works as it is told]
  • use an alternate port for your secure channel
    Any unused port, like: https://rpiben.ddns.net:9443/
3 Likes

Hi,
I decided to run a basic script to see if any issue with the router not forwarding the 443 port for https.
Context : Flask webserver with ssl_context pointing to the re-generated letsencript certificate & key.for the host rpiben.ddns.net
$ sudo certbot certonly --standalone
The script:

-------------------------------
from flask import Flask
port = '8000'
app = Flask(__name__)
@app.route('/')
def hello_world():
    return 'Hello, World! Message from Falsk app - port: '+port
if __name__ == '__main__':
    app.run(host='0.0.0.0', debug = True, port=port,
                ssl_context=(
                       '/etc/letsencrypt/live/rpiben.ddns.net/fullchain.pem',
                       '/etc/letsencrypt/live/rpiben.ddns.net/privkey.pem')
            )
----------------------------

From the terminal :
$ sudo python3 flask-ssl-test.py

* Serving Flask app "flask-ssl-test" (lazy loading)
* Environment: production
* Debug mode: on
* Running on https://0.0.0.0:8000/ (Press CTRL+C to quit)

From there I can access the server via https://rpiben.ddns.net:8000/ and get the expected response . So, the router is working ok.

BUT:
When I run the ssl test via ssllabs I still get the error message "Certificate name mismatch "

I did not find the error when using apache & Co, but at least I'm able to expose the Flask web server in a secure environment, which was my initial objective. I still need to use a WSGI for production.

Thanks for any comment, suggestion...

Benoit.

1 Like

SSL Labs connects only to port 443.

That's a whole other thing.

3 Likes

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