regarding ssl certificates

[Joseph Tam]

On Thu, 14 Mar 2019, John Tulp wrote:

> Encryption is just really not that much of a barrier any more.

Spoken like someone who hasn't actually tried breaking any of these
algorithms.  It's not like every, or event most, cryptologists who
designs these algorithms, or analyzes them for weaknesses, are in the
pocket of the NSA or private interests.  Lots of people try really,
really hard to find even the slightest flaw.

If you're saying it's easier to do an end-run around it, then yes, but
that just emphasizes breaking encryption is much harder than alternate
methods.

Gary wrote:

> Is there some reason to use a mail.domain.com cert for mail rarher than
> just using domain.com for everything?

If you want all your SSL enabled services tied to one fully-qualified
domain name, then sure.

Even if you have a single swiss-army knife server, you may still want to
use multiple-service names for flexibility.  For example, you may want
to scale out in the future by offloading/autsourcing to another server.
You may want to transition to a replacement platform without having to
migrate all your services in one fell swoop.

Having service hostnames allow you to dissociate a service from the
server's hostname.

Michael A. Peters writes:

> With SMTP, the hostname should match the reverse IP though often it
> does not.

In the context of certificate authenticity, a forward DNS mapping
suffices.  Even for spam scoring, FcRDNS is only a weak inference to
authenticity.

Joseph Tam <jtam.home at gmail.com>