Does Kumo recognize TLS certs for wildcard domains

get-help
1

I am experiencing TransientFailures because the TLS cert isn’t matching the delivery domain. The situation is the cert is a wildcard and the delivery domain is a host deep under the wildcarded domain.

MX Server in question is a CNAME to mx.hostedemail.com run by OpenSRS
Specifically, the server responds with a TLS cert for: TLS peer DN="/C=CA/ST=Ontario/L=Toronto/O=Tucows Inc/CN=*.hostedemail.com"
The mx domain it is supposed to handling data for is something like mx.emailhome.com.cust.a.hostedemail.com

Is the rejection coming from Kumo not treating the deeply nested domain as covered by the wildcard?

2

Hey there @impressive-porcupine, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.

3

Please share the TransientFailure log record that you are seeing

4

I have done almost all my testing with a wildcard cert and have not seen any issues. As Wez said above, please provide the transfail log, or the general log that includes the transfails so we can see the actual error. Also please share the debug journal and init.lua

5

I will gather the info to reproduce it when I have spare time. I do not want to show the actual domain and email account, but I will redo it with demo/disposable info that can be published. In the meantime I switched that domain to be OpportunisticInsecure in the shaping.toml for the interim

Also I found this that says (with regard to web ssl) wildcard domains should only cover one level and the wildcard should only cover the leftmost host, so it would seem a cert for *.example.com should not be valid for sub2.sub1.example.com - https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain I would assume the mail TLS would follow the same conventions, and therefore it is an issue with the way that OpenSRS is using their wildcard cert. Is it not the case?

6

@faithful-ostrich when you say you tested with a wildcard cert, are you also saying that the cert had covered a deeply nested subdomain and that didn’t produce issues?

7

As an aside, if Opportunistic allows for non-TLS communication, why wouldn’t it assume OpportunisticInsecure? Wouldn’t it make more logical sense for the edge case to be OpportunisticSecure?

8

without the actual domain, we cannot help you debug what is happening in this specific circumstance. What I would have done with that information is:

  1. dig mx DOMAIN to determine the MX hostname
  2. openssl s_client -starttls smtp -crlf -connect MXHOSTNAME:25 -showcerts to verify that the certificate is correctly provisioned for the host
9

In the past, when this question has come up, it has been due to an invalid CN on the cert deployed by the destination

10

Insecure allows for bogus mismatched certificates to be returned. If that was the default it would make kumomta trivially vulnerable to MITM attacks

11

it is exactly as described…

swaks -tls --quit-after=STARTTLS --server mx.emailhome.com.cust.a.hostedemail.com --port 25

I will set up an email on those servers for testing…

12

I was using Opportunistic and it was failing

13

is the mail being sent to some-user@mx.emailhome.com.cust.a.hostedemail.com ?

14

email going to user@emailhome.com mx is mx.emailhome.com.cust.a.hostedemail.com cert DN is *.hostedemail.com

15

and what do you see in the TransientFailure log?

16

the issue is cert for *.hostedemail.com being used for mx.emailhome.com.cust.a.hostedemail.com

17

yeah, the * cannot match multiple sub-domains

18

the failure is … ..[domain].com.cust.a.hostedemail.com.", addr: 216.40.42.4 }:25 failed: invalid peer certificate: NotValidForName

19

yep, the cert is not valid for the domain in the MX record

20

well that is a major email provider doing it wrong…