Is there some reason to use a mail.domain.com cert for mail rarher than just using domain.com for everything? Historically the subdomain were used because they were on different hardware. That is www was on one machine and mail was on another. ? Original Message ? From: dovecot at dovecot.org Sent: March 14, 2019 3:56 PM To: dovecot at dovecot.org Reply-to: jtam.home at gmail.com Subject: Re: regarding ssl certificates mick crane wrote:> Apache2 default install has this snake oil certificate > Can make a new one for apacheI won't go over some of the excellent points in previous posts, but I will mention SAN as a third type of certificate you can make. LetsEncrypt supports this type of certificate. This is halfway between single CN and wildcard certificate where you can combine many hostnames (up to 1000?) into one certificate.? This may be useful if you want the convenience of handling fewer certificates, without having an unbounded wildcard certificate (the latter also requires control over your DNS).? I use this for SMTPAUTH, POP3, IMAP and webmail services since they are all on one server. Then Stephan von Krawczynski wrote:> Sorry I have to write this, but this is again pointing people in a fake > security direction. > The only valid authority for a certificate is the party using it. Any third > party with unknown participants cannot be a "Certificate Authority" in its > true sense. This is why you should see "Let's Encrypt" simply as a cheap way > to fake security. It is a US entity, which means it _must_ hand out all > necessary keys to fake certificates to the US authorities _by law_. > Now probably you can imagine why they are giving the certificates out for > free. US authorities can compromise all of them - without any "open knowledge".Wow, you packed a lot of fear, uncertainty and doubt (and some misinformation) into one paragraph.? I'll leave it at that. Joseph Tam <jtam.home at gmail.com>
With PKIX validation the certificate should match the hostname. With SMTP, the hostname should match the reverse IP though often it does not. Using subdomains gives you flexibility. with DANE validation, it is DNSSEC that validates the fingerprint to the hostname so I do not believe there is a need for the hostname in the cert to match anything, but DANE validation is currently not used by any mail user agents, only PKIX validation is used by mail user agents. DANE is used to MTA to MX quite frequently however, so it may come to mail user agents in the near future (near being within a decade or so). On 3/14/19 10:03 PM, Gary via dovecot wrote:> Is there some reason to use a mail.domain.com cert for mail rarher than just using domain.com for everything? > > Historically the subdomain were used because they were on different hardware. That is www was on one machine and mail was on another. > > > > > > ? Original Message > > > > From: dovecot at dovecot.org > Sent: March 14, 2019 3:56 PM > To: dovecot at dovecot.org > Reply-to: jtam.home at gmail.com > Subject: Re: regarding ssl certificates > > > mick crane wrote: > >> Apache2 default install has this snake oil certificate >> Can make a new one for apache > > I won't go over some of the excellent points in previous posts, > but I will mention SAN as a third type of certificate you can make. > LetsEncrypt supports this type of certificate. > > This is halfway between single CN and wildcard certificate where you can > combine many hostnames (up to 1000?) into one certificate.? This may > be useful if you want the convenience of handling fewer certificates, > without having an unbounded wildcard certificate (the latter also requires > control over your DNS).? I use this for SMTPAUTH, POP3, IMAP and webmail > services since they are all on one server. > > Then Stephan von Krawczynski wrote: > >> Sorry I have to write this, but this is again pointing people in a fake >> security direction. >> The only valid authority for a certificate is the party using it. Any third >> party with unknown participants cannot be a "Certificate Authority" in its >> true sense. This is why you should see "Let's Encrypt" simply as a cheap way >> to fake security. It is a US entity, which means it _must_ hand out all >> necessary keys to fake certificates to the US authorities _by law_. >> Now probably you can imagine why they are giving the certificates out for >> free. US authorities can compromise all of them - without any "open knowledge". > > Wow, you packed a lot of fear, uncertainty and doubt (and some > misinformation) into one paragraph.? I'll leave it at that. > > Joseph Tam <jtam.home at gmail.com> >
I do whatever Google requires not to look like spam. Fortunately the don't insist on DANE. I was just concerned about the encryption being secure. I used to use a self signed cert until Google made it to your advantage to use encryption on websites. Once I set up Let's Encrypt, it seemed dumb to use the self signed cert. On a quarterly basis the email agents warns about the cert change. If Let's Encrypt goes to monthly cert renewal, this is going to get a little tiresome. I recently modified the bash based ACME to reload Dovecot and Postfix. The programs eventually adjusted to the cert update, but the email agents weren't happy for an hour or two. The GitHub documentation for the ACME script indicates how to do this. ? Original Message ? From: dovecot at dovecot.org Sent: March 15, 2019 12:07 AM To: dovecot at dovecot.org Reply-to: mpeters at domblogger.net Subject: Re: regarding ssl certificates With PKIX validation the certificate should match the hostname. With SMTP, the hostname should match the reverse IP though often it does not. Using subdomains gives you flexibility. with DANE validation, it is DNSSEC that validates the fingerprint to the hostname so I do not believe there is a need for the hostname in the cert to match anything, but DANE validation is currently not used by any mail user agents, only PKIX validation is used by mail user agents. DANE is used to MTA to MX quite frequently however, so it may come to mail user agents in the near future (near being within a decade or so). On 3/14/19 10:03 PM, Gary via dovecot wrote:> Is there some reason to use a mail.domain.com cert for mail rarher than just using domain.com for everything? > > Historically the subdomain were used because they were on different hardware. That is www was on one machine and mail was on another. > > > > > > ? Original Message > > > > From: dovecot at dovecot.org > Sent: March 14, 2019 3:56 PM > To: dovecot at dovecot.org > Reply-to: jtam.home at gmail.com > Subject: Re: regarding ssl certificates > > > mick crane wrote: > >> Apache2 default install has this snake oil certificate >> Can make a new one for apache > > I won't go over some of the excellent points in previous posts, > but I will mention SAN as a third type of certificate you can make. > LetsEncrypt supports this type of certificate. > > This is halfway between single CN and wildcard certificate where you can > combine many hostnames (up to 1000?) into one certificate.? This may > be useful if you want the convenience of handling fewer certificates, > without having an unbounded wildcard certificate (the latter also requires > control over your DNS).? I use this for SMTPAUTH, POP3, IMAP and webmail > services since they are all on one server. > > Then Stephan von Krawczynski wrote: > >> Sorry I have to write this, but this is again pointing people in a fake >> security direction. >> The only valid authority for a certificate is the party using it. Any third >> party with unknown participants cannot be a "Certificate Authority" in its >> true sense. This is why you should see "Let's Encrypt" simply as a cheap way >> to fake security. It is a US entity, which means it _must_ hand out all >> necessary keys to fake certificates to the US authorities _by law_. >> Now probably you can imagine why they are giving the certificates out for >> free. US authorities can compromise all of them - without any "open knowledge". > > Wow, you packed a lot of fear, uncertainty and doubt (and some > misinformation) into one paragraph.? I'll leave it at that. > > Joseph Tam <jtam.home at gmail.com> >
On 03/15/2019 06:03 AM, Gary wrote:> Is there some reason to use a mail.domain.com cert for mail rarher than > just using domain.com for everything? > > Historically the subdomain were used because they were on different > hardware. That is www was on one machine and mail was on another.Actually *THE* original approach was a) to make ftp.mydom.ain a CNAME to machine4711.mydom.ain or similar, b) attaching that latter (usually by A and PTR RRs) to the physical hardware for its lifetime, and c) use the naked mydom.ain for e-mail addresses and thus, since MX RRs did not yet exist back then, have its A or CNAME RR point to your incoming SMTP server. When it became apparent that using the domain name - typically representing your organization as a whole - for a specific service wasn't *that* bright an idea, the e-mail aspect was repaired by the introduction of MX RRs. During the time that took to get implemented everywhere, other services still used ftp.*, gopher.*, what have you, even the early www.* . Then came the day when Eric Allman decided that the new version of sendmail shall replace CNAMEs in e-mail addresses, local admin's opinion on the matter and existing working setups be damned. As far as I can tell, *that's* what ended the era of the "functional names shall be CNAMEs" paradigm. *Today* web designers opine that an organization's website is *so* important that it merits repeating the old error of putting it under mydom.ain instead of www.mydom.ain, even if it's hosted someplace that's not under *your* control in the first place. I'm fighting that wherever I can (and unlike many of those "professionals", I *do* have the technology at hand to have something respond to HTTP(S) at mydom.ain and throw back a HTTP redirect to www.mydom.ain). Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4278 bytes Desc: S/MIME Cryptographic Signature URL: <https://dovecot.org/pipermail/dovecot/attachments/20190315/ebc91cc6/attachment-0001.p7s>