Does filling out the Country Name, State etc. matter when creating a self-signed certificate for Postfix?

Question

When I set up Postfix I have to create a cert because the snakeoil cert included with Postfix is there strictly for the purpose of demonstration. I use this command:

sudo openssl req -x509 -newkey rsa:4096 -sha512 -keyout postfix-key.pem -out postfix-cert.pem -days 3650

This prompts me with Country Name, State or Province Name, etc.

Is there any purpose in the context of Postfix that one would bother to fill out the certificate as accurately as possible instead of using the defaults? I'm trying to make my Postfix server as legit as possible to avoid blacklisting and such, so I am wondering if filling out the cert as accurately as possible would make any difference, for example, when sending an email from my Postfix server to a Gmail account.

Answer 1

If you’re happy to have that information in the public domain, it doesn’t do any harm to fill it in. However, there’s no real need to broadcast this data (e.g., as a private citizen, I dislike having that kind of information publicised in the WHOIS database). For receiving MTAs to accept SMTP over TLS, you don’t even have to ensure that the FQDN of your mail server is listed in the certificate Common Name or DNS Names (Subject Alternative Name) as is required for HTTPS.

In my experience, the details of X.509 certificate has no bearing on whether a remote MTA treats SMTP connections as legitimate. I conducted an experiment just now by reconfiguring my Postfix server to use an X.509 certificate that had expired 6 days ago and sent a few emails using it. All receiving MTAs accepted the messages; GMail headers verified that the message had been received via TLS 1.2.

Using a non-blacklisted IP address and configuring SPF, DKIM, Forward-confirmed reverse DNS and other related techniques are the best ways for your email to be treated as legitimate.

Currently, most mail servers are configured to accept self-signed certificates for SMTP over TLS but that may not remain the case over the coming years. To be on the safe side, I ensure that my mail server’s FQDN is included in the certificate’s DNS Names (Subject Alternative Name) and that the certificate is signed (gratis) by the awesome Let’s Encrypt Certificate Authority.

Answer 2

Opportunistic TLS

Mail servers generally do not require validating "who" you are; and thus, a self signed cert is sufficient in most cases. My mail server regenerates its self signed certs hourly, because.

[snip]

openssl req -new -subj "/CN=${fqdn}" -key ${dir}/${ymd}.key -out ${dir}/${ymd}.csr

openssl x509 -req -days 2 -in ${dir}/${ymd}.csr -sha256 -CA ${dir}/${ymd}.ca.crt -CAkey ${dir}/${ymd}.ca.key -set_serial ${ymd} -out ${dir}/${ymd}.crt

The above is a snippet of all I have ever used. ${ymd} is just a date for the file. ${fqdn} is the DNS name of my mail server.

In some cases, a business-to-business relationship may require validating "who" you are. In that case, you would want a signed cert, or set up a shared public CA cert between your orgs if you do not trust a CA for your use case. Some financial orgs do this.

Answer 3

There is no reason to put all of the information in to the self signed certificate. The only reason is if a user wants to inspect it.