Re: regarding ssl certificates
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
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
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
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
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
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
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
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
(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
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
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
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
-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
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
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
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
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
