[SOLVED] SMTP vs API/GUI Hostname

[utkonos]

I use a different hostname for SMTP and API/GUI. The certificates are separate. However, I want to understand what the best practice is because I may have done this reverse from what it should be.

PMG IP: 192.0.2.1

The ACME settings are:

mx.example.com -> smtp
hostxyz123.example.com -> api

The DNS records are:

A mx.example.com -> 192.0.2.1
A hostxyz123.example.com -> 192.0.2.1
MX mx.example.com
PTR 192.0.2.1 -> hostxyz123.example.com

When setting up the PMG, during the Management Network Configuration the hostname was set to "hostxyz123.example.com".

The effect of this last choice is that the SMTP banner and hostname added to various Received headers and other places all show hostxyz123.example.com.

Should the hostname of the management network actually have been set to mx.example.com? If not, is there a setting to make the SMTP components show mx.example.com?
Lastly, is it better to set the PTR record to mx.example.com?

 

[Stoiko Ivanov]

The question is - why not keep everything as 'mx.example.com' - why do you need a dedicated hostname for accessing the API/Quarantine-interface?

else - in general I'd recommend to have a 'clean' setup from mail perspective - meaning:
* the hostname your MX records point to (mx.example.com) resolves to the IP-address (192.0.2.1)
* the PTR of the IP resolves to mx.example.com
* the hostname of the machine is set to mx.example com (this should take care of HELO-name, smtpd banner, and the received headers)

If you additionally want to have hostxyz123.example.com (maybe for pointing your users there for their quarantine) - just add an A/AAAA (to the ip) /CNAME (to mx.example.com)

for the acme-certificates - why not simply add both hostnames to both certificates - can be done in the GUI

for changing a PMG's hostname see the page in the wiki:
https://pmg.proxmox.com/wiki/index.php/Change_FQDN

I hope this helps!

 

[utkonos]

I think this is exectly the right advice. Fortunately this is just a test environment, so I will just burn it down and make these changes to the deployment process.

I think adding both names to the to the API/GUI cert makes complete sense, but I think leaving the SMTP cert with just the mx.example.com name leaves it cleaner. There are no circumstances where I would want someone using hostxyz123.example.com to make an SMTP connection that I can think of.

 

[utkonos]

@Stoiko Ivanov A CNAME or separate A record doesn't work with the 8006 GUI. If I make the hostname during install mx.example.com then I cannot use the cname or the other A record hostname to login to the GUI. When I try to use that other hostname, the login process ends in a fail.

I think I'm chasing something that fundamentally doesn't matter and is pointless to continue to bother with it. I will just use mx.example.com for all the things.

On a side note: why is there a separate SSL certificate for API and SMTP if the hostname doesn't function unless they're both the same?

 

[utkonos]

Argh. There is just an intermediate condition where you can only use the CNAME to access to instance after the certificate is properly installed.

So, using mx.example.com for the hostname is correct. Using hostxyz123.example.com for the API/GUI is also correct. However, the hostxyz123.example.com CNAME cannot be used to login to the GUI until after the certificate has been properly installed. otherwise the login process ends with a failure.

 

[Stoiko Ivanov]

So, using mx.example.com for the hostname is correct. Using hostxyz123.example.com for the API/GUI is also correct. However, the hostxyz123.example.com CNAME cannot be used to login to the GUI until after the certificate has been properly installed.

Why can't it be used? The only thing that comes to my mind is that you get a certificate warning if the CNAME is not added as SAN to the certificate ...

which error did you get exactly - what's the certificate state?

 

[utkonos]

@Stoiko Ivanov It can be used, there is just an intermediate state when the cert has not been installed and the instance is using its self-signed cert where there is a login failure if using the CNAME in the URL. Once the cert is installed, everything works as expected. This is a test instance, so I will be building the production instance at some point soon. I will be going through this exact same process again and I can look at the Chrome console logs to see if there are any informative error messages.