Re: regarding ssl certificates

2019-03-15 Thread Joseph Tam via dovecot

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 


Re: Re: regarding ssl certificates

2019-03-15 Thread Jochen Bern via dovecot
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



smime.p7s
Description: S/MIME Cryptographic Signature


Re: regarding ssl certificates

2019-03-15 Thread Gary via dovecot

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@dovecot.org
Sent: March 15, 2019 12:07 AM
To: dovecot@dovecot.org
Reply-to: mpet...@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@dovecot.org
> Sent: March 14, 2019 3:56 PM
> To: dovecot@dovecot.org
> Reply-to: jtam.h...@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 
>



Re: regarding ssl certificates

2019-03-15 Thread Michael A. Peters via dovecot

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@dovecot.org
Sent: March 14, 2019 3:56 PM
To: dovecot@dovecot.org
Reply-to: jtam.h...@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 





Re: regarding ssl certificates

2019-03-14 Thread Gary via dovecot
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@dovecot.org
Sent: March 14, 2019 3:56 PM
To: dovecot@dovecot.org
Reply-to: jtam.h...@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 


Re: regarding ssl certificates

2019-03-14 Thread John Tulp via dovecot


On Thu, 2019-03-14 at 15:08 +0100, Stephan von Krawczynski via dovecot
wrote:
> On Thu, 14 Mar 2019 09:51:14 -0400
> Phil Turmel via dovecot  wrote:
> 
> > On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote:
> > 
> > > Sorry I have to write this, but this is again pointing people in a fake
> > > security direction.  
> > 
> > You should be sorry, because you are wrong.
> > 
> > > 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_.  
> > 
> > Certificate authorities, including Let's Encrypt, operate on Certificate 
> > Signing Requests, not Private Keys.  Some CAs do offer private key 
> > generation in their services for the user's convenience, but it is not 
> > recommended (obviously) and in no way required.  Getting a CA to sign a 
> > CSR in no way exposes keys to that CA, and therefore not to any government.
> > 
> > While there are weakness in the CA trust system, they aren't anything 
> > related to replacing a snakeoil cert with one from Let's Encrypt.
> > 
> > [rest of ignorant rant trimmed]
> 
> Some facts for you, as obviously you have not understood what a CA is worth
> that is compromised by either hackers or "authorities".
> If you want to know more, read articles about closing of CA DigiNotar, like:
> https://en.wikipedia.org/wiki/DigiNotar
> 
> Then read US export laws concerning security devices.
> Then judge your US-issued certs...
>  
> > Phil
> 
I concur Stephan; I apologize to others if I seem ignorant.

Just an FYI, a founder of Let's Encrypt, and host of it's website is
Akamai, which also hosts nsa.gov, cia.gov, etc.  Akami principal
founders were a US guy and a US/Israeli spy guy.

I once did a traceroute on the mailserver that sent me an email (from a
bank); the route went over to Europe, to Virginia, back to Europe, then
back to me (in the US).  It made me laugh it was so obvious.  The bank's
service provider that provided the email service ?  Akamai.

Any time you're using the "internet", well, let's just say that many
very intelligent people are quite naive when it comes to internet
security.

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

Developers are always told "don't roll your own encryption".  Well, to
even set up encryption software (algo selection, etc.), it's something
that is beyond most of us.  I always try to do at least some minimal
research to see "what's what", and with encryption it always boils down
to having very low confidence that what I'm setting up would take more
than a few minutes for a serious "invader" to totally break through.

Encryption is being used to promote a false sense of security.

It could only be more obvious if NSA directly sold certificates
themselves.  I'm sure there would be many very intelligent folks who
would happily purchase them and think they were the greatest thing since
sliced bread.

To close rant, in my humble opinion sure, encrypt if you like, give it
your best effort, but don't assume that anything is "secure".



Re: regarding ssl certificates

2019-03-14 Thread Joseph Tam via dovecot

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 


Re: regarding ssl certificates

2019-03-14 Thread Phil Turmel via dovecot

On 3/14/19 10:08 AM, Stephan von Krawczynski via dovecot wrote:


Some facts for you, as obviously you have not understood what a CA is worth
that is compromised by either hackers or "authorities".
If you want to know more, read articles about closing of CA DigiNotar, like:
https://en.wikipedia.org/wiki/DigiNotar


I am well aware of what happens when a CA is compromised and 
man-in-the-middle attacks become possible.  Your initial mail implied 
that the user's own keys would be compromised.  Running your own CA is 
quite useless for asserting one's identity to random other mail servers 
as you'd have to get them all to trust you as a CA, with exactly the 
same problems as any other CA, with anonymity tacked on.  DNSSEC would 
be wonderful if it was commonly supported, but we ain't there yet.


The point is that a cert from any currently recognized cert authority is 
*operationally* better than a snakeoil cert.  The practical impact of 
your initial advice is "don't run a mail server".


Also, secrets don't last -- nobody trusts anything that came from 
DigiNotar.  That will happen to any CA caught issuing bogus certs, 
regardless for whom.



Then read US export laws concerning security devices.
Then judge your US-issued certs...


Totally orthogonal to the problem of mutual trust for mail handling.


Re: Re: regarding ssl certificates

2019-03-14 Thread Jochen Bern via dovecot
(Sorry for the broken references, my MUA misplaced the e-mail I'm
*actually* replying to.)

On 03/14/2019 03:08 PM, Stephan von Krawczynski wrote:
> Some facts for you, as obviously you have not understood what a CA is worth
> that is compromised by either hackers or "authorities".
> If you want to know more, read articles about closing of CA DigiNotar, like:
> https://en.wikipedia.org/wiki/DigiNotar
> 
> Then read US export laws concerning security devices.
> Then judge your US-issued certs...

Out of interest, does(*) or doesn't(**) your scenario include mechanisms
like HPKP?

(*) I'm not aware of any MUAs implementing one, just browsers, and it's
now being phased out by *them* in favor of CT, too.

(**) If not, the question of what CAs issued any *legit* certs for you
has no practical relevance on whether and which other CAs may get hacked
or judicially suborned into creating a working fraudulent one.

(Where "practical" means "you cannot expect the entire, possibly
worldwide, user population to manually strip their clients' list of
accepted CAs down to the one *you* chose".)

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect



smime.p7s
Description: S/MIME Cryptographic Signature


Re: regarding ssl certificates

2019-03-14 Thread Stephan von Krawczynski via dovecot
On Thu, 14 Mar 2019 09:51:14 -0400
Phil Turmel via dovecot  wrote:

> On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote:
> 
> > Sorry I have to write this, but this is again pointing people in a fake
> > security direction.  
> 
> You should be sorry, because you are wrong.
> 
> > 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_.  
> 
> Certificate authorities, including Let's Encrypt, operate on Certificate 
> Signing Requests, not Private Keys.  Some CAs do offer private key 
> generation in their services for the user's convenience, but it is not 
> recommended (obviously) and in no way required.  Getting a CA to sign a 
> CSR in no way exposes keys to that CA, and therefore not to any government.
> 
> While there are weakness in the CA trust system, they aren't anything 
> related to replacing a snakeoil cert with one from Let's Encrypt.
> 
> [rest of ignorant rant trimmed]

Some facts for you, as obviously you have not understood what a CA is worth
that is compromised by either hackers or "authorities".
If you want to know more, read articles about closing of CA DigiNotar, like:
https://en.wikipedia.org/wiki/DigiNotar

Then read US export laws concerning security devices.
Then judge your US-issued certs...
 
> Phil

-- 
MfG,
Stephan von Krawczynski


--
ith Kommunikationstechnik GmbH

Lieferanschrift  : Reiterstrasse 24, D-94447 Plattling
Telefon  : +49 9931 9188 0
Fax  : +49 9931 9188 44
Geschaeftsfuehrer: Stephan von Krawczynski
Registergericht  : Deggendorf HRB 1625
--



Re: regarding ssl certificates

2019-03-14 Thread Phil Turmel via dovecot

On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote:


Sorry I have to write this, but this is again pointing people in a fake
security direction.


You should be sorry, because you are wrong.


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_.


Certificate authorities, including Let's Encrypt, operate on Certificate 
Signing Requests, not Private Keys.  Some CAs do offer private key 
generation in their services for the user's convenience, but it is not 
recommended (obviously) and in no way required.  Getting a CA to sign a 
CSR in no way exposes keys to that CA, and therefore not to any government.


While there are weakness in the CA trust system, they aren't anything 
related to replacing a snakeoil cert with one from Let's Encrypt.


[rest of ignorant rant trimmed]

Phil


Re: regarding ssl certificates

2019-03-14 Thread Kostya Vasilyev via dovecot
On Thu, Mar 14, 2019, at 2:51 PM, Nikolai Lusan via dovecot wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> So this question means you need to do some more reading about all SSL/TLS
> services.
> 
> On Thu, 2019-03-14 at 10:46 +, mick crane via dovecot wrote:
> > Excuse dopey question.
> > I'm not exactly clear about certificates.
> > Apache2 default install has this snake oil certificate
> > Can make a new one for apache
> > Can make one for dovecot
> > Can make one for ssl
> > Is there supposed to be the one (self signed ) certificate pair in one 
> > place for the machine that each process hands out ?
> > Can they be moved to another machine ?
> 
> In general you can have one certificate per hostname ('host.domain.com'),
> or you can have a wildcard certificate that is valid for
> '*.example.domain'. 

Or you can use one cert with additional hostnames (domains) in that single 
cert's subjectAltName's.

> The alternative to paid signed certificates is using letsencrypt 
> https://letsencrypt.org - they can do both individual certificates and
> wildcard certificates.

With letsencrypt these (single cert with subjectAltName's) are easier to 
validate than wildcards IIRC (http based vs. DNS based validation).

-- K


Re: regarding ssl certificates

2019-03-14 Thread Nikolai Lusan via dovecot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

So this question means you need to do some more reading about all SSL/TLS
services.

On Thu, 2019-03-14 at 10:46 +, mick crane via dovecot wrote:
> Excuse dopey question.
> I'm not exactly clear about certificates.
> Apache2 default install has this snake oil certificate
> Can make a new one for apache
> Can make one for dovecot
> Can make one for ssl
> Is there supposed to be the one (self signed ) certificate pair in one 
> place for the machine that each process hands out ?
> Can they be moved to another machine ?

In general you can have one certificate per hostname ('host.domain.com'),
or you can have a wildcard certificate that is valid for
'*.example.domain'. The "snakeoil" certificates that you refer to are
generally self signed certificates, and yes you can create as many self
signed certs as you want. You can pay someone to sign your certificates for
you (wildcards may, or may not, be more cost effective in this case. They
are certainly more portable). Signed certificates should match the
hostnames they are used for, this is where wildcard certificates are of
use. The alternative to paid signed certificates is using letsencrypt 
https://letsencrypt.org - they can do both individual certificates and
wildcard certificates.

There are pro's and con's for both paid and free signed certificates, but
you should use _a_ signed certificate for any TLS based service that
communicates with anything in the wild (i.e. non-internal services, public
mail servers, public web servers). Personally I use letsencrypt wildcards
with domain based authentication for automatic certificate renewal
(although distributing the certificates across servers can be an
"interesting" problem to deal with). 

- -- 
Nikolai Lusan 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlyKP/gACgkQ4ZaDRV2V
L6TswQ/9ERKEwSyy0aN0rS9axIB8bd5oGKBr3UhYY/rdsHaKj/c2PzbPHSoeyGFp
89ZRDChzrkwMqdDJTSzxYVA0+C4Vak0OKf3SUvHwCGdX4O2MDfPHXw5+4YDftjgn
oSaW2RmKmIQvfK8qKg4n8C+xDif54/20MwZaytSG/y7NikOt+3T8ph3UAO+HBD4G
7DMA/MKn0XX6pU8uhEbovU2ne4uUgl5FnncMcY9ibm8/4eEsqO5SU8DMwZtPG8Ux
4bPejIKf/L/5sFJw2wHI9vld3NTebklIK1eK1Vgw7en9Fmt/ydn+JXvxtDQa7YZS
gp0fN8r5SMiClrOvFkZVS3oJo2lklq+KJsMaD14l52HKmHZXNBUpZQI8dk/J+Q7c
m3liElPdTbZ+DK5c9koQqB8w49JfqWV9JFHhgY5WEntLvROarSOKn3GHy0DkDa6c
W2cQY8aOMM8FHsIqhsM0gKsNe8Q2aHPM/UoNJaWBrhoXnT/lEzUN3FNIbq7yj4cb
wXGQzZeFpcCaIb5SvMUl9yl8THZ2DpWsIFJOqYOmWMf1iiKLWu6bAh61sNYBWePQ
S+pwk55AOGQUf73ElpGBCJOjrLgt/ADIluNkO1fI9bKQQjSIQRfEX5LWQPLwz8z8
Z+cyZc2ufW6F+F13n1yHSFEYFwbjAIdM06dATbsrlNh7PyNYeFE=
=w9R4
-END PGP SIGNATURE-



Re: regarding ssl certificates

2019-03-14 Thread Stephan von Krawczynski via dovecot
On Thu, 14 Mar 2019 12:13:15 +0100
"Guido Goluke, MajorLabel via dovecot"  wrote:

> Op 14-03-19 om 11:46 schreef mick crane via dovecot:
> > Excuse dopey question.
> > I'm not exactly clear about certificates.
> > Apache2 default install has this snake oil certificate
> > Can make a new one for apache
> > Can make one for dovecot
> > Can make one for ssl
> > Is there supposed to be the one (self signed ) certificate pair in one 
> > place for the machine that each process hands out ?
> > Can they be moved to another machine ?
> >
> > mick
> >  
> 
> Apache, dovecot and Postfix can all use the same certificate, you do 
> need to configure each one to the location of the certificate though. 
> SSL is something else: apache, dovecot, postfix are all 
> services/programs. SSL is a protocol/way of encryption. Self-signed 
> means there is no Certificate Authority backing the legitimacy. Getting 
> a Let's Encrypt certificate (I recommend certbot) will get you a 
> legitime certificate, but only for the hostname (e.g. 
> web01.yourdomain.com) you provide it. This must be traceable to your 
> machine through DNS, so moving it to another machine would only work if 
> that machine would completely replace the old machine (domain name) and 
> the DNS is changed to point to your new IP address (or the old machine 
> gets taken out of 'the air' and the new machine gets the old one's IP 
> address).
> 
> Best.
> 
> MajorLabel

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".
It would be dead easy to prevent this fake for the guys at mozilla or google
(for the web), but they don't. All that is needed is a trivial DNS-based way
to check self-signed certificates at the corresponding domain, let's say some
host pointed to by a SRV entry.
If you think DNS (not DNSSEC which has the same immanent problem) can be
compromised too, well, yes, but then the access to hosts in that domain will
be compromised anyway and a certificate will not save you at all. 


-- 
Regards,
Stephan



Re: regarding ssl certificates

2019-03-14 Thread Guido Goluke, MajorLabel via dovecot



Op 14-03-19 om 11:46 schreef mick crane via dovecot:

Excuse dopey question.
I'm not exactly clear about certificates.
Apache2 default install has this snake oil certificate
Can make a new one for apache
Can make one for dovecot
Can make one for ssl
Is there supposed to be the one (self signed ) certificate pair in one 
place for the machine that each process hands out ?

Can they be moved to another machine ?

mick



Apache, dovecot and Postfix can all use the same certificate, you do 
need to configure each one to the location of the certificate though. 
SSL is something else: apache, dovecot, postfix are all 
services/programs. SSL is a protocol/way of encryption. Self-signed 
means there is no Certificate Authority backing the legitimacy. Getting 
a Let's Encrypt certificate (I recommend certbot) will get you a 
legitime certificate, but only for the hostname (e.g. 
web01.yourdomain.com) you provide it. This must be traceable to your 
machine through DNS, so moving it to another machine would only work if 
that machine would completely replace the old machine (domain name) and 
the DNS is changed to point to your new IP address (or the old machine 
gets taken out of 'the air' and the new machine gets the old one's IP 
address).


Best.

MajorLabel



Re: regarding ssl certificates

2019-03-14 Thread Yassine Chaouche via dovecot

On 3/14/19 11:46 AM, mick crane via dovecot wrote:

Excuse dopey question.
I'm not exactly clear about certificates.
Apache2 default install has this snake oil certificate
Can make a new one for apache
Can make one for dovecot
Can make one for ssl
Is there supposed to be the one (self signed ) certificate pair in one 
place for the machine that each process hands out ?

Can they be moved to another machine ?

mick


Not a dovecot specific question, but I use the same certificate for 
apache, dovecot and postfix, for my domain name, on any number of 
machines, except they must all have the same hostname (they don't all 
have the same name at the same time).


I see no difference between a self-signed certificate and a broken 
certificate. In both cases you have warnings in the browser/mail client. 
In both cases you need to hit the "accept anyway" button.


Yassine.



regarding ssl certificates

2019-03-14 Thread mick crane via dovecot

Excuse dopey question.
I'm not exactly clear about certificates.
Apache2 default install has this snake oil certificate
Can make a new one for apache
Can make one for dovecot
Can make one for ssl
Is there supposed to be the one (self signed ) certificate pair in one 
place for the machine that each process hands out ?

Can they be moved to another machine ?

mick

--
Key IDC7D6E24C