Wildcard certificate not applied to all services

[tz-mbc]

Hi there, I have inherited a 2 server OpnSense cluster setup (21.7.6-amd64) which is humming nicely for more than a year, but now that I need to connect a new service I ran into an issue I struggle to figure out myself.

My setup exposes two IPs per server (one physical/ one virtual) which are tied to their associated FQDN = mail.mydomain.com and out.mydomain.com

My problem is that this new service (GMail) reports that one of the FQDNs hasn't got a valid certificate.
mail.mydomain.com:25 is ok according to Google
out.mydomain.com:25 is not.

What I don't understand is where and how I map the wildcard certificate (visible under /System/Trust) to a IP/FQDN. I am actually surprised that this cert isn't automatically used for all ports and all interfaces hosted on this server?

I searched high and low for settings which would map FQDN or NAT to the existing wildcard cert without success. So my only "logical" explanation is that somehow the certificate is maybe tied to only the first WAN interface mail.*) and not to the virtual IP which out.* points to? But then again, I can't find a way to map the cert to the virtual IP either.

If anyone could provide some ideas as to what and where to look I'd be grateful.

By the way, by joining this forum I also realised that 21.7* is considered legacy, I will have to look into upgrading once this certificate stull is sorted out.

[Vilhonator]

If you have used Let's encrypt to sign those certificates, then you need to go to let's encrypts settings and check that certificate in question has mydomain.com as FQDN and alias contains mail.mydomain.com and out.mydomain.com.

You also must make sure, that domain you registered has wildcard support (some Domain providers charge extra for that).

If you don't use Let's encrypt, then you need to contact your certificate provider and ask them for assistance.

I don't run my own mail servers, so I can't tell exactly how certs work on mail servers. All I had to do to get certificates was to add domain key provided by my mail server provider to DNS records.

[tz-mbc]

Thanks for joining in Vilhonator, that's a good idea, it didn't occur to me to check if the individual FQDN are listed in the cert.
But unfortunately they are not, not for the working mail.mydomain.com nor for the failing out.mydomain.com.

Here's what the respective section looks like when I select info for the certificate in OpnSense:

X509v3 Extended Key Usage:
               TLS Web Server Authentication, TLS Web Client Authentication
 X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
                DNS:*.mydomain.com, DNS:mydomain.com

I guess that means this certificate should get handed out for all connection requests, no matter the subdomain?
The certificate is issued by certum.pl, not Letsencrypt.

One other idea I had was that maybe the cert is handed out by OpnSense at all but by one of the services NAT redirects to, in my case that's a Proxmox Mail Gateway. But this server hasn't got the certificate loaded so I wouldn't know how it gets injected.

<<All I had to do to get certificates was to add domain key provided by my mail server provider to DNS records.>>
That's for the dkim keys I think? My issue is related to establishing a TLS connection between Gmail and my server,

[Vilhonator]

<<All I had to do to get certificates was to add domain key provided by my mail server provider to DNS records.>>
That's for the dkim keys I think? My issue is related to establishing a TLS connection between Gmail and my server,

Does your mail have DMARC records on it's DNS? If it's just matter of google not trusting your certificate, it might be due to lack of DMARC records. I know that relays are not trusted 100% without any proof that they aren't being used to spam.

https://mxtoolbox.com/ has good free tools with checking the mx records and DMARC and dmarcian.com helps you with that.

Other than that, issue isn't in firewall (as long as you can send and/or recieve mail using other mail mail service, it means things work, google is just quite strict about these things since a lot of people used to use their mail for spamming and scams)

You will have to check your domains info if it supports wildcards. Wildcard certificates are used to assign same sertificate for FQDN and x amount of it's sub domains.

You won't be able to assign wildcard certificates for domains, which providers do not allow it. I would recommend contacting your domain provider, server customer support and certificate provider about this

[Vilhonator]

Also you don't have to use certificate for your mail.mydomain.com and out.mydomain.com if mail address which you send mail to is admin@mydomain.com.

mail.mydomain.com and out.mydomain.com are just something you need to add to dns records, to tell which server recieves mail and which sends it, inbox and outbox both use FQDN certificate, at least to my knowledge

[tz-mbc]

Thanks again Vilhonator, I am not sure if my issue is specific to email, I am setting up an email relay which technically is a simple network connection protected by TLS. I don't see how any of the higher level email checks would be relevant here. But nevertheless, yes DMARC, SPF and DKIM are all set for this domain.
I actually use both of these FQDNs for relaying email from/to Office365, and that works. Maybe because Microsoft doesn't check the cert.

I attached a screenshot which shows the Gmail dialogs side by side.
Both mail.mydomain.com and out.mydomain.com point to the same server, the only difference (I am aware of) is different IP addresses/interfaces where OpnSense picks up the traffic.
And my question comes down to if the cert gets picked up for mydomain.com what could prevent OpnSense from providing the same cert to out.mydomain.com

You raised a valid point that out.mydomain.com may not be listed in the cert, but given that the cert contains *.mydomain.com, all subdomains should be served, and it does seem to work for mail.mydomain.com.

Let me rephrase the questions slightly: is adding a certificate to the OpnSense trust store sufficient for it to be used for all FQDNs listed in the certificate, or do I need to specifically assign the certificate to a WAN interface/NAT rule/ anything? If the answer is that this certificate will be used for all services, I may be hitting the wrong bush. E.g. OpnSense provides the correct cert but Gmail for some reason is not happy with it which would mean I can tick off OpnSense and need to continue troubleshooting at that end.

[Vilhonator]

Sorry can't help with that. I would contact certificate issuer and ask help from google as well.

Opnsense isn't able to force any certificates to you (it doesn't even check if you are using valid certificate or not, when you send certificate validation request to google, opnsense will send it even if it's invalid and response you get is how google sees it)

Proxy certificates, VPN certificates etc. are all authenticated by servers not firewall (unless you are using IPS function). Just by it's own, firewall only blocks, rejects, passes and forwards traffic based on rules it has.

[tz-mbc]

Just to close this off, I think I got to the bottom of my issue. Indeed not related to OpnSense but rather the cert settings of a server behind NAT.
Once I knew where to look I found this command which allowed me to identify the server which responded with the wrong certificate:

openssl s_client -starttls smtp -showcerts -connect out.mydomain.com:25 -servername out.mydomain.com

Thanks for helping me along!