Lets Encrypt for Webmin

Help
1

CentOS 7
webmin-1.974-1.noarch

https://africanstudios.net:10000 gives results ERR_SSL_VERSION_OR_CIPHER_MISMATCH
while https://africanstudios.net and all other domains work fine.

I recently requested a new Let's Encrypt certificate from the webmin control panel as it expired.

I can access all others certifcates and ssl on all other hosts without issue. However I cannot access port 10000 which webmin uses to access control panel.

I suspect this is an issue with webmin and their implementation of Let's encrypt as I have no other issue with certbot of configurations. Webmin creates seperate certificates inside /etc/webmin/

2

The issue is with the configuration of whatever service is bound to port 10000.

Ports 80 (HTTP)/443 (HTTPS) are served by Apache.

Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.4.33

Port 10000 is served by MiniServe and responding to HTTP requests with a redirect to https on the same port

Server: MiniServ/1.974

I am fairly confident the following is happening:

Port 10000 fails with HTTPS requests, because it is not configured to serve HTTPS. The problem is not with the Certificates, but with the server configuration itself. You are trying to serve HTTP and HTTPS on the same port (10000) ~~ - you can not do that~~. The HTTPS requests are failing, because the port appears to be configured for HTTP instead of HTTPS, and trying to speak HTTPS to an HTTP endpoint will generate the errors you noted.

You will need to reconfigure the port 10000 service appropriately. if you need to support both http and https, you need to decouple that onto two different ports (edit: added the following) or have a properly configured server that can speak both on the same port. if you only need to support https, you need to configure that service to speak HTTPS and not HTTP.

5 Likes
3

Thank you for the response. I will try to configure :10000 only for https. The current configuration was working fine until I renewed the certificate today. But I am happy to be pointed in the right direction.

4

That's not entirely correct: It is technically perfectly possible to speak HTTP and HTTPS simultaneously on the same port. Some webservers can do this.

The webserver in question here responds with a HTTP-to-HTTPS redirect on HTTP requests, which indeed indicates it does speak at least HTTP. When sending a TLS handshake request, the server responds with a TLS Alert code 40 "handshake error". This shows that the service is capable of also speaking TLS: It understands TLS Client Hellos and responds with a TLS alert protocol message.

The reason for the service replying with handshake errors is unknown though. Perhaps a misconfiguration, or an internal server error - logs could be helpful.

7 Likes
5

That is true. It have had such limited experience with it, I totally forgot about it. Thank you for the correction.

5 Likes
6

[Wed Mar 08 17:48:34.946798 2023] [ssl:warn] [pid 8760] AH01909: RSA certificate configured for africanstudios.net:443 does NOT include an ID which matches the server name
[Wed Mar 08 17:48:34.947371 2023] [ssl:warn] [pid 8760] AH01909: RSA certificate configured for africanstudios.net:443 does NOT include an ID which matches the server name
[Wed Mar 08 17:48:34.948510 2023] [ssl:warn] [pid 8760] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Wed Mar 08 17:48:34.951659 2023] [so:warn] [pid 8760] AH01574: module proxy_module is already loaded, skipping
[Wed Mar 08 17:48:34.959063 2023] [so:warn] [pid 8760] AH01574: module proxy_module is already loaded, skipping
[Wed Mar 08 17:48:35.034217 2023] [ssl:warn] [pid 8760] AH01909: RSA certificate configured for africanstudios.net:443 does NOT include an ID which matches the server name
[Wed Mar 08 17:48:35.035807 2023] [ssl:warn] [pid 8760] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Wed Mar 08 17:48:35.081356 2023] [mpm_prefork:notice] [pid 8760] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.4.33 configured -- resuming normal operations
[Wed Mar 08 17:48:35.081427 2023] [core:notice] [pid 8760] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'

7

I added servername africanstudios.net to httpd.conf. That removed some errors not sure if I need add something else.

8

httpd.conf is and those logs are for Apache

Your problem is with whatever service is listening to port 10000

4 Likes
9

that's miniserv.conf.
Working on the configurations now. Hopefully it's as simple as adding updated ciphers and making sure the ssl mods are compatible. I dont know what caused this problem. My server has been running with current configuration for years. But I will keep searching then post the solution

4 Likes
10

Please see Security/Server Side TLS - MozillaWiki and to assist with configuration there is
https://ssl-config.mozilla.org/

2 Likes
11

I have no idea what could have broken that, as swapping a Certificate should not have changed it. I looked at their docs and am lost, your update must have lost some command - either in the config file, shell environment or commandline. I like to store configuration files in version control so I can audit changes when things break like this - perhaps you have an old version?

A way to help debug this is using curl:

curl -I -k -v https://africanstudios.net:10000/ --trace foo.txt

I just gets the headers, k ignores any cert validty, and v shows verbose output. --trace foo.txt writes an expanded trace/log to foo.txt .

I took out a few lines, but the error seems to be the server response.

== Info:   Trying 64.202.187.35...
== Info: TCP_NODELAY set
== Info: Connected to africanstudios.net (64.202.187.35) port 10000 (#0)
== Info: ALPN, offering h2
== Info: ALPN, offering http/1.1
== Info: Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
== Info: successfully set certificate verify locations:
== Info:   CAfile: /etc/ssl/cert.pem
  CApath: none
== Info: TLSv1.2 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 224 bytes (0xe0)
...
== Info: TLSv1.2 (IN), TLS alert, Server hello (2):
<= Recv SSL data, 2 bytes (0x2)
0000: 02 28                                           .(
== Info: error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
== Info: stopped the pause stream!
== Info: Closing connection 0

It looks to be sending an empty response - no cert, no ciphers, no anything. Just 2 bytes.

3 Likes
12

Thanks. I have been working on my conf file and still no luck. But i am convinced the problem is in
the miniserv.conf.

port=10000
addtype_cgi=internal/cgi
realm=Webmin Server
logfile=/var/webmin/miniserv.log
errorlog=/var/webmin/miniserv.error
pidfile=/var/webmin/miniserv.pid
logtime=168
ssl=1
no_ssl2=1
no_ssl3=1
no_tls1=1
no_tls1_1=1
no_tls1_2=0
ssl_honorcipherorder=1
no_sslcompression=1
env_WEBMIN_CONFIG=/etc/webmin
env_WEBMIN_VAR=/var/webmin
atboot=1
logout=/etc/webmin/logout-flag
listen=10000
denyfile=.pl$
log=1
blockhost_failures=5
blockhost_time=60
syslog=1
ipv6=1
session=1
premodules=WebminCore
userfile=/etc/webmin/miniserv.users
keyfile=/etc/letsencrypt/live/XXXXXXX/privkey.pem
passwd_file=/etc/shadow
passwd_uindex=0
passwd_pindex=1
passwd_cindex=2
passwd_mindex=4
passwd_mode=0
preroot=authentic-theme
passdelay=1
login_script=/etc/webmin/login.pl
logout_script=/etc/webmin/logout.pl
cipher_list_def=1
failed_script=/etc/webmin/failed.pl
error_handler_403=403.cgi
error_handler_404=404.cgi
error_handler_401=401.cgi
nolog=/stats.cgi?xhr-stats=general
certfile=/etc/letsencrypt/live/XXXXXXX/cert.pem
ssl_redirect=0
no_resolv_myname=0
sockets=
extracas=/etc/letsencrypt/live/XXXXXXX/chain.pem
root=/usr/libexec/webmin
mimetypes=/usr/libexec/webmin/mime.types
server=MiniServ/2.013
ssl_hsts=0
ssl_cipher_list=ssl_cipher_list=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA

1 Like
13

Thanks for the info. Big help in narrowing down the problem. I reached out the webmin community and saw the problem was fixed by update algos but no one has current solution. Seems a recent update broke the ssl but I cant get a confirmation,

3 Likes
14

I honestly can't tell what is going on here. After a bit of digging, miniserv is is not the "miniserv" project but an internal script in webmin.

The config docs are here:

I see you have a ticket open with them already. That's basically the only thing I could have suggested. I hope you figure this out quickly!

3 Likes
15

Yeah, thanks for your help. I

3 Likes
16

In the webmin github issue, someone suggested it may be due to the certificate having an ECC key.

You can try using certbot to get a new certificate with an RSA key using the --key-type rsa command. That may get you back up and running until a proper fix is figured out.

It also might not work at all, but that might get you back online.

4 Likes
17

When all things are equal.
But when changing from RSA to ECC, all things are no longer equal.

How many times do you see "RSA" in this?:

2 Likes
18

I am just trying all the recommendations. If you have a better cipher that works. I will apprectiate it.

19

I use:
"ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"

3 Likes
20

Tired yours and it didnt work. Ran across something obvious, still running OpenSSl 1.0.2k , will upgrade that over the weekend. Most likely that will solve my issue.

1 Like