SSL domain using self-signed CA works for MQTT but fails for HTTPS

Virtualmin
21

I think the issue is our Webmin/virtualmin is not providing SNI correctly. I’m sure its an easy fix ?

here is the Apcahe Error Log entry:

[ssl:error] [pid 843455:tid 123…] [client aa.bb.cc.dd:60576] AH02032: Hostname domain1.com (default host as no SNI was provided) and hostname domain2.com provided via HTTP have no compatible SSL setup

we have a shared fixed ip aa.bb.cc.dd
we have external DNS at registra, and have A records for each virtualmin domain, but all use the same IP

The client embedds the cert as the ca.pem for the virtualmin domain (domain2.com)
but the server default is domain1.com

how can we fix this “default host as no SNI was provided” ?
…

I fixed this my side, on the client. for those who stumble on this in the future, within the TLS, set :
.skip_cert_common_name_check = false, //set the Server Name Indication (SNI)

22

OK, so the SNI is the fix for and MAIN domain, but does NOT fix a subdomain
the subdomain still has:
E (50931) esp-tls-mbedtls: mbedtls_ssl_handshake returned -0x2700
I (50931) esp-tls-mbedtls: Failed to verify peer certificate!

we are using a LE cert:
Common Name (CN) = mqtt.domain.com
Issued by:
|Common Name (CN)|R13|
|Organization (O)|Let’s Encrypt|

so its not a cert issue, but a subdomain issue.

23

I can’t keep up with what you’re trying to do. I thought you were trying to use certs signed with your own CA, rather than Let’s Encrypt, so you can have it not expire for many years?

We know SNI works fine in the default Apache or nginx configuration Virtualmin produces, including for sub-servers (whether a subdomain name or not) with Let’s Encrypt certs and any modern browser. So, first confirm it’s working in modern browsers with whatever your current server configuration is, so you can narrow the problem down to an issue with your HTTPS client (which I’m pretty sure this continues to be).

You really need to narrow down what problem you’re trying to solve. Stop changing variables. I can’t keep up, and you will never understand the problem if everything is different in every experiment.

24

we have narrowed this down

  1. the domain.com works, so its specific to the subdomain
  2. rulled out the self-signed cert, as the LE cert fails

so, could be
a) the clinet TLS (mbedtls)
b) dns ?
c) ?

25

ok, so the good news, all work ok (domain or subdomain, LE or self-signed certs).

the issue was on a server with multiple domains (i.e Webmin running multiple Virtualmin) and only 1 IP address, that SNI / CN has to be enforced, hence in a client with mbedtls, you have to set “.common_name” to be the same as the domain you are trying to reach over HTTPS, i.e

common_name = “mqtt.domain.com”

and for the client cert that is embedded to initiate a HTTPS TLS link, always attach the root ca

Either LE (LetsEncrypt) or Self-Signed certs work (even though the later will NOT show a padlock icon, it’s still secure HTTPS for OTA file transfers)

I have attached a write-up here
Compare domain certs domain.com vs mqtt.domain.com vs1_0.pdf.zip (191.3 KB)

1 Like
26

You can make it valid by adding the CA cert to your system CA bundle (or otherwise making the client trust the CA).

27

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