# Lets Encrypt for Webmin

**URL:** <https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137>\
**Category:** Help\
**Created:** [March 8, 2023, 10:59pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137 "2023-03-08T22:59:14Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 8, 2023, 10:59pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/1 "2023-03-08T22:59:14Z")

</div>

CentOS 7  
webmin-1.974-1.noarch

**[https://africanstudios.net:10000](https://africanstudios.net:10000) gives results ERR\_SSL\_VERSION\_OR\_CIPHER\_MISMATCH**  
while [https://africanstudios.net](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/

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 8, 2023, 11:19pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/2 "2023-03-08T23:19:52Z")

</div>

> [@AfricanStudios](#):
>
> 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/

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.

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 8, 2023, 11:35pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/3 "2023-03-08T23:35:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\
**Post date:** [March 8, 2023, 11:48pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/4 "2023-03-08T23:48:01Z")

</div>

> [@jvanasco](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 9, 2023, 12:07am UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/5 "2023-03-09T00:07:08Z")

</div>

> [@Nummer378](#):
>
> It is technically perfectly possible to speak HTTP and HTTPS simultaneously on the same port

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

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 1:16am UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/6 "2023-03-09T01:16:04Z")

</div>

[Wed Mar 08 17:48:34.946798 2023] [ssl:warn] [pid 8760] AH01909: RSA certificate configured for [africanstudios.net:443](http://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](http://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](http://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'

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 1:30am UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/7 "2023-03-09T01:30:11Z")

</div>

I added servername [africanstudios.net](http://africanstudios.net) to httpd.conf. That removed some errors not sure if I need add something else.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 9, 2023, 2:02am UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/8 "2023-03-09T02:02:09Z")

</div>

> [@AfricanStudios](#):
>
> I added servername [africanstudios.net](http://africanstudios.net) to httpd.conf.

httpd.conf is and those logs are for Apache

Your problem is with whatever service is listening to port 10000

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 2:08pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/9 "2023-03-09T14:08:47Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bruce5051](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruce5051/32/76576_2.png) [@Bruce5051](https://community.letsencrypt.org/u/Bruce5051)\
**Post date:** [March 9, 2023, 3:57pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/10 "2023-03-09T15:57:05Z")

</div>

> [@AfricanStudios](#):
>
> Hopefully it's as simple as adding updated ciphers

Please see [Security/Server Side TLS - MozillaWiki](https://wiki.mozilla.org/Security/Server_Side_TLS) and to assist with configuration there is  
[https://ssl-config.mozilla.org/](https://ssl-config.mozilla.org/)

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 9, 2023, 5:12pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/11 "2023-03-09T17:12:20Z")

</div>

> [@AfricanStudios](#):
>
> My server has been running with current configuration for years.

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.

```nohighlight
== 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.

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 5:20pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/12 "2023-03-09T17:20:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 5:25pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/13 "2023-03-09T17:25:03Z")

</div>

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,

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 9, 2023, 6:42pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/14 "2023-03-09T18:42:29Z")

</div>

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:

> <https://github.com/webmin/webmin/blob/0fcce117a186426bd83f9d8c4ce09587cae3a6a5/webmin/lang/en#L381>

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!

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 9, 2023, 6:44pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/15 "2023-03-09T18:44:35Z")

</div>

Yeah, thanks for your help. I

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [March 10, 2023, 6:23pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/16 "2023-03-10T18:23:18Z")

</div>

In the [webmin github issue](https://github.com/webmin/webmin/issues/1854), 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.

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [March 13, 2023, 9:59pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/17 "2023-03-13T21:59:37Z")

</div>

> [@jvanasco](#):
>
> swapping a Certificate should not have changed it

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?:

> [@AfricanStudios](#):
>
> 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

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 13, 2023, 11:24pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/18 "2023-03-13T23:24:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [March 14, 2023, 12:43am UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/19 "2023-03-14T00:43:34Z")

</div>

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"

---

<div class="post-metadata">

**Author:** ![AfricanStudios](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/africanstudios/32/68422_2.png) [@AfricanStudios](https://community.letsencrypt.org/u/AfricanStudios)\
**Post date:** [March 14, 2023, 3:53pm UTC](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137/20 "2023-03-14T15:53:26Z")

</div>

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.

[Next page](https://community.letsencrypt.org/t/lets-encrypt-for-webmin/194137.md?page=2)
