is a self signed certificate always invalid the first time?
So i’m using dovecot, and i created a self signed certificate with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
The first time it connects in mac mail however, it says the certificate is invalid and another server might pretend to be me etc.
I then have the option of trusting it.
Is this normal behaviour? Will it always be invalid if it’s not signed by a third party?
Thank you.
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
Thanks Greg, that makes total sense. Appreciate your reply.
On 9 Aug 2017, at 16:39, Gregory Sloop <gregs@sloop.net<mailto:gregs@sloop.net>> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus.
-- Regards, Stephan
I completely agree (having said that I'm pretty new to all this so I might be full of it).
You should run your own CA if you have an active financial interest in your company (say your the owner). No added benefit to have your certificate certified by a third party, why would they care about that one client). Ofcourse people would say "but ofcourse you would verify your own certificate" but in that case they probably don't understand how it all works.
Ofcourse once your own company grows large you run the same risk of entropy (incorrect documentation or records, no trained staff, no up to date procedures etc.) large companies have to deal with. Maybe if you had one person working full time on it, or an automated process handling things it would be more secure and reliable.
Was diginotar the Dutch company, I think I remember that one.
Sent from my iPhone
On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus.
-- Regards, Stephan
On 10 August 2017, at 04:37, Alef Veld <alefveld@outlook.com> wrote:
I completely agree (having said that I'm pretty new to all this so I might be full of it).
You should run your own CA if you have an active financial interest in your company (say your the owner). No added benefit to have your certificate certified by a third party, why would they care about that one client). Ofcourse people would say "but ofcourse you would verify your own certificate" but in that case they probably don't understand how it all works.
Ofcourse once your own company grows large you run the same risk of entropy (incorrect documentation or records, no trained staff, no up to date procedures etc.) large companies have to deal with. Maybe if you had one person working full time on it, or an automated process handling things it would be more secure and reliable.
Was diginotar the Dutch company, I think I remember that one.
Sent from my iPhone
On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus.
-- Regards, Stephan
If you use a self-signed certificate, your users either have to accept the certificate when requested, or install your root certificate. Installing the root certificate is not easy to explain to non-tech users even with step-by-step instructions with screen shots attached. I have gone this approach ever since the RSA patents expired and it can be a pain at times. Users just don't understand the obnoxious warning (panic) messages the browsers put out that are intended to keep them from accepting self-signed certificates. The browser developers don't understand the certificate trust issues either. Several Microsoft versions did not provide a way to accept the certificates. Those users were forced to install your root certificate. However, as stated before, if you are only certifying your own certificates, then that is the most appropriate approach.
-- Doug
I can't see any security advantages of a self signed cert. If the keypair is generated locally (which it should) a certificate signed by an external CA can't be worse just by the additional signature of the external CA.
Better security can only be gained if all users are urged to remove all preinstalled trusted CAs from their mail clients (which seems impractical). Else an attacker could still use a fake cert signed by one of those CAs. Public key pinning could be an (academic) alternative and would still work with a cert signed by an external CA without restrictions.
If someone tells me to add security exceptions this rings all alarm bells. Users who are not experts should not get used to doing this as they soon will accept everything.
Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie <bc979@lafn.org>:
On 10 August 2017, at 04:37, Alef Veld <alefveld@outlook.com> wrote:
I completely agree (having said that I'm pretty new to all this so I might be full of it).
You should run your own CA if you have an active financial interest in your company (say your the owner). No added benefit to have your certificate certified by a third party, why would they care about that one client). Ofcourse people would say "but ofcourse you would verify your own certificate" but in that case they probably don't understand how it all works.
Ofcourse once your own company grows large you run the same risk of entropy (incorrect documentation or records, no trained staff, no up to date procedures etc.) large companies have to deal with. Maybe if you had one person working full time on it, or an automated process handling things it would be more secure and reliable.
Was diginotar the Dutch company, I think I remember that one.
Sent from my iPhone
On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus.
-- Regards, Stephan
If you use a self-signed certificate, your users either have to accept the certificate when requested, or install your root certificate. Installing the root certificate is not easy to explain to non-tech users even with step-by-step instructions with screen shots attached. I have gone this approach ever since the RSA patents expired and it can be a pain at times. Users just don't understand the obnoxious warning (panic) messages the browsers put out that are intended to keep them from accepting self-signed certificates. The browser developers don't understand the certificate trust issues either. Several Microsoft versions did not provide a way to accept the certificates. Those users were forced to install your root certificate. However, as stated before, if you are only certifying your own certificates, then that is the most appropriate approach.
-- Doug
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Having gone through the process to get "approved" certificates a few times, I don't believe it would be all that difficult to get a certificate with your domain name from several of the "approved" certificate authorities. The process some of them use to "certify" the applicant is pretty easy to spoof. Clearly the hackers don't see that as much of an obstacle.
-- Doug
On 10 August 2017, at 13:41, Frank-Ulrich Sommer <f-u.s@gmx.net> wrote:
I can't see any security advantages of a self signed cert. If the keypair is generated locally (which it should) a certificate signed by an external CA can't be worse just by the additional signature of the external CA.
Better security can only be gained if all users are urged to remove all preinstalled trusted CAs from their mail clients (which seems impractical). Else an attacker could still use a fake cert signed by one of those CAs. Public key pinning could be an (academic) alternative and would still work with a cert signed by an external CA without restrictions.
If someone tells me to add security exceptions this rings all alarm bells. Users who are not experts should not get used to doing this as they soon will accept everything.
Am 10. August 2017 21:40:25 MESZ schrieb Doug Hardie <bc979@lafn.org>:
On 10 August 2017, at 04:37, Alef Veld <alefveld@outlook.com> wrote:
I completely agree (having said that I'm pretty new to all this so I might be full of it).
You should run your own CA if you have an active financial interest in your company (say your the owner). No added benefit to have your certificate certified by a third party, why would they care about that one client). Ofcourse people would say "but ofcourse you would verify your own certificate" but in that case they probably don't understand how it all works.
Ofcourse once your own company grows large you run the same risk of entropy (incorrect documentation or records, no trained staff, no up to date procedures etc.) large companies have to deal with. Maybe if you had one person working full time on it, or an automated process handling things it would be more secure and reliable.
Was diginotar the Dutch company, I think I remember that one.
Sent from my iPhone
On 10 Aug 2017, at 08:18, Stephan von Krawczynski <skraw@ithnet.com> wrote:
On Wed, 9 Aug 2017 08:39:30 -0700 Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
This was exactly the global thinking - until the day DigiNotar fell. Since that day everybody should be aware that the true problem of a certificate is not its issuer, but the "trusted" third party CA. This could have been known way before of course by simply thinking about the basics. Do you really think your certificate gets more trustworthy because some guys from South Africa (just an example) say it is correct, running a _business_? Honestly, that is just naive. It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain. Because only then the only one being responsible and trustworthy is yourself. And that is the way it should be. Everything else involving third party business is just bogus.
-- Regards, Stephan
If you use a self-signed certificate, your users either have to accept the certificate when requested, or install your root certificate. Installing the root certificate is not easy to explain to non-tech users even with step-by-step instructions with screen shots attached. I have gone this approach ever since the RSA patents expired and it can be a pain at times. Users just don't understand the obnoxious warning (panic) messages the browsers put out that are intended to keep them from accepting self-signed certificates. The browser developers don't understand the certificate trust issues either. Several Microsoft versions did not provide a way to accept the certificates. Those users were forced to install your root certificate. However, as stated before, if you are only certifying your own certificates, then that is the most appropriate approach.
-- Doug
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote:
I can't see any security advantages of a self signed cert. I
then you fail to understand the history, like when Microsoft's certs were undermined because the third party authentication agency gave the keys to 2 guys that knocked on the door and asked for them...
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Am 11. August 2017 12:46:46 MESZ schrieb Ruben Safir <ruben@mrbrklyn.com>:
On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote:
I can't see any security advantages of a self signed cert. I
then you fail to understand the history, like when Microsoft's certs were undermined because the third party authentication agency gave the keys to 2 guys that knocked on the door and asked for them...
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Of course I know about this risk. But the only way to reduce it is to remove all preinstalled root CAs from all devices you use. It's more important whoom your client trusts than who signed your cert.
Using a self signed cert alone and still using a client with a huge list of preinstalled root CAs will be exactly as vulnerable as using a regular cert with this client. The client will accept a spoofed cert that was fraudulently obtained from one of those root CAs in both cases.
If you configure your client such that it only accepts certs that you manually added you could (theoretically and from a security standpoint) still use certs signed by an external CA that you add manually without compromising security. It's only important that you don't let someone else (e.g. the CA because it's easier...) generate your key pair but that you generate it yourself and only submit a certificate signing request.
On 08/10/2017 04:41 PM, Frank-Ulrich Sommer wrote:
add security exceptions this rings all alarm bells.
no, but software vendors will have you believe that. Sorry, I don't leave my house keys with strangers
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
On 10.08.2017 09:18, Stephan von Krawczynski wrote:
It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain.
I have been running a CA for 15+ years, generating certificates only for servers I personally maintain. Since my business is too small to be able to afford all the steps required to have my CA trusted by Mozilla, Apple etc., this approach leaves me with the same problem self-signed certs have: How can I make third party applications like web browsers or MUAs trust the certs I created?
For some of my customers, I can add my CA certs (root and intermediary) to their keystores, so the end user does not see a thing. For other customers, I can hand over cert fingerprints so end users can manually accept the connections after checking the fingerprint (guess how many users actually do that).
Naturally, this does not work for publicly available services, where there is currently no alternative to using well-known CAs. Of course their certs are not technically better than my own CA's or than self- signed certs, and their processes are sometimes garbage, the fuckups of Symantec being case in point. Symantec even just sold off their whole CA business to DigiCert; it seems they never really recovered from generating fake google.com certificates two years ago:
https://security.googleblog.com/2015/09/improved-digital-certificate-securit...
To get back on topic: if the OP can live with self-signed certs, that's perfectly fine. If Alef needs people to be able to connect to his Dovecot server without verifying/confirming the certificate, a CA like Let's Encrypt is a better choice. As far as Postfix is concerned, there is hardly any reason to use a well-known CA, because opportunistic TLS for SMTP does not care about trust chains.
-Ralph
I just need my internal users to download their mail, right now it's not something I'm terribly worried about. I'm just glad I got it all working so far :-)
Once I do my apache to SSL as well I'll probably get paid certificates or one letsencrypt certificate for all.
Sent from my iPhone
On 10 Aug 2017, at 12:43, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 10.08.2017 09:18, Stephan von Krawczynski wrote:
It would be far better to use a self-signed certificate that can be checked through some instance/host set inside your domain.
I have been running a CA for 15+ years, generating certificates only for servers I personally maintain. Since my business is too small to be able to afford all the steps required to have my CA trusted by Mozilla, Apple etc., this approach leaves me with the same problem self-signed certs have: How can I make third party applications like web browsers or MUAs trust the certs I created?
For some of my customers, I can add my CA certs (root and intermediary) to their keystores, so the end user does not see a thing. For other customers, I can hand over cert fingerprints so end users can manually accept the connections after checking the fingerprint (guess how many users actually do that).
Naturally, this does not work for publicly available services, where there is currently no alternative to using well-known CAs. Of course their certs are not technically better than my own CA's or than self- signed certs, and their processes are sometimes garbage, the fuckups of Symantec being case in point. Symantec even just sold off their whole CA business to DigiCert; it seems they never really recovered from generating fake google.com certificates two years ago:
https://security.googleblog.com/2015/09/improved-digital-certificate-securit...
To get back on topic: if the OP can live with self-signed certs, that's perfectly fine. If Alef needs people to be able to connect to his Dovecot server without verifying/confirming the certificate, a CA like Let's Encrypt is a better choice. As far as Postfix is concerned, there is hardly any reason to use a well-known CA, because opportunistic TLS for SMTP does not care about trust chains.
-Ralph
I have looked at let's encrypt. Key issue for me is having to add a lot python stuff that would otherwise not be on any server.
Again, All CA's like "Let's Encrypt" - and others that are accepted by the "majors", e.g., Windows, Mozilla make it much easier for the "random" user to use anything you protect with SSL (better TLS) without them having to grant "trust" manually. That "trust" is indicated because the CA that signed your certificate is recognized by a CA, that is recognized by CA, that is recognized by a CA in the "root-trust" list that the "majors" make available (e.g., the mozilla list available via the curl site (https://curl.haxx.se/docs/caextract.html)).
Now - back to Ralph's comment:
On 8/10/2017 1:42 PM, Ralph Seichter wrote:
I have been running a CA for 15+ years, generating certificates only for servers I personally maintain. Since my business is too small to be able to afford all the steps required to have my CA trusted by Mozilla, Apple etc., this approach leaves me with the same problem self-signed certs have: How can I make third party applications like web browsers or MUAs trust the certs I created? Rather than make the mistake I did years ago by make "unique" self-signed certificates for different servers - start out with a self-signed certificate that you use as a signing certificate. This is what Ralph means when he says "have been running a CA for 15+ years" - not that he is (though he could!) sell certificates commercially - rather, he is using an initial certificate to sign later certificates with. So, his "users" only need to add the public side of his signing certificate - and any certificate he has signed meets the "chain of trust".
So, if your users are "random", i.e., can come from anywhere - you may want a "major accepted/recognized" certificate authority so that you do not have to distribute your signing key. However, if your user pool is "select", or otherwise known - requiring them to use your "self-signed" CA may be a positive, rather than a negative.
Again, technically, there is no difference in a self-signed 2048-bit RSA key, and one signed by a "major" CA. However, in the "ease of use" there may be major differences.
And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. :)
On 2017-08-11 11:36, Michael Felt wrote:
I have looked at let's encrypt. Key issue for me is having to add a lot python stuff that would otherwise not be on any server.
I use acme.sh for all of my LetsEncrypt certs (web & mail), it is written in pure shell script, so no python dependencies. https://github.com/Neilpang/acme.sh
On 8/11/2017 11:44 AM, Florian Beer wrote:
On 2017-08-11 11:36, Michael Felt wrote:
I have looked at let's encrypt. Key issue for me is having to add a lot python stuff that would otherwise not be on any server.
I use acme.sh for all of my LetsEncrypt certs (web & mail), it is written in pure shell script, so no python dependencies. https://github.com/Neilpang/acme.sh Thanks - I might look at that, but as Ralph mentions in his reply - Let's encrypt certs are only for three months - never ending circus.
On 18.08.2017 08:58, Michael Felt wrote:
as Ralph mentions in his reply - Let's encrypt certs are only for three months - never ending circus.
I don't consider the 90-day-lifespan a "circus". It is meant as a security feature[1], and Let's Encrypt suggests using automation for certificate renewal. Also, with ACME v2 on the horizon[2], I imagine that more automation tools will become available.
[1] https://letsencrypt.org/2015/11/09/why-90-days.html [2] https://letsencrypt.org/2017/06/14/acme-v2-api.html
Let's not forget that Let's Encrypt is still a young service, and that it is free.
-Ralph
On 11.08.2017 11:36, Michael Felt wrote:
This is what Ralph means when he says "have been running a CA for 15+ years" - not that he is (though he could!) sell certificates commercially - rather, he is using an initial certificate to sign later certificates with.
Actually, I do sell certificates to my customers. :-) In small numbers, and only for servers to which I have administrative access. I created a root CA and two intermediate CAs (one each for client and server certs, respectively).
It would be great to have my CAs added to Mozilla's NSS root certificate store, but alas, the effort to get there is massive. Where possible, I will add my CA certs to the customers' keystores. I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually.
Again, technically, there is no difference in a self-signed 2048-bit RSA key, and one signed by a "major" CA. However, in the "ease of use" there may be major differences.
In 2015 I rolled out an updated CA which I have used ever since, with 4096 bit keys for root and intermediary CA certs. I also only generate 4096 bit keys for servers these days, so my cert chain is "stronger" than those of some commercial CAs. Also, it is good to know that these certs have never been touched by anybody but myself. I even install my own CA cert chain on my iOS devices.
And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA.
I encourage you to look into the subject again. With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-)
-Ralph
On 11.08.2017 11:36, Michael Felt wrote:
This is what Ralph means when he says "have been running a CA for 15+ years" - not that he is (though he could!) sell certificates commercially - rather, he is using an initial certificate to sign later certificates with. Actually, I do sell certificates to my customers. :-) In small numbers, and only for servers to which I have administrative access. So, not really "selling", but an additional service. I created a root CA and two intermediate CAs (one each for client and server certs, respectively).
It would be great to have my CAs added to Mozilla's NSS root certificate store, but alas, the effort to get there is massive. Where possible, I will add my CA certs to the customers' keystores. I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually.
Again, technically, there is no difference in a self-signed 2048-bit RSA key, and one signed by a "major" CA. However, in the "ease of use" there may be major differences. In 2015 I rolled out an updated CA which I have used ever since, with 4096 bit keys for root and intermediary CA certs. I also only generate 4096 bit keys for servers these days, so my cert chain is "stronger" than those of some commercial CAs. Also, it is good to know that these certs have never been touched by anybody but myself. I even install my own CA cert chain on my iOS devices.
And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. I encourage you to look into the subject again. I actually have been, which is why I could give a near sensible reply. Thanks for the encouragement! With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) I should know all three, but, sadly, only one: two things to add to my
On 8/11/2017 1:29 PM, Ralph Seichter wrote: list of things to research.
-Ralph
On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:
On 8/11/2017 1:29 PM, Ralph Seichter wrote:
And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. I encourage you to look into the subject again.
I actually have been, which is why I could give a near sensible reply. Thanks for the encouragement!
With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) I should know all three, but, sadly, only one: two things to add to my list of things to research.
I have been reading this with some interest (while trying to migrate Dovecot, Postfix etc..)
BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ?
(I'm currently using self issued for both mail and web)
thanks,
V
On Fri, August 18, 2017 5:02 pm, Michael Felt wrote:
On 8/11/2017 1:29 PM, Ralph Seichter wrote:
And, Ralph, I salute you. I have never been able to be disciplined enough to be my own CA. I encourage you to look into the subject again.
I actually have been, which is why I could give a near sensible reply. Thanks for the encouragement!
With the advent of Let's Encrypt, free certs for the masses have become a thing, but if you need more than 3 months validity, want to create certs for Intranet-devices (routers, local servers), or just want maximum control over all certs, setting up your own CA is rewarding. While you're at it, no gentleman should not be without DNSSEC, DKIM and DANE these days. ;-) I should know all three, but, sadly, only one: two things to add to my list of things to research.
I have been reading this with some interest (while trying to migrate Dovecot, Postfix etc..)
BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ?
(I'm currently using self issued for both mail and web) Above - Ralph added: I also made my CA certs available for public download, so tech-savvy users can import the CA certs manually. Depending on your site-popularity (aka number of "random" users) you could also instruct them how to access your signing key. Once they had
On 8/18/2017 9:12 AM, voytek@sbt.net.au wrote: that, they would auto-magically, recognize any other keys you signed with your CA "roots".
In other words, if the work to you to instruct users to use your CA is more expensive than using a commercial CA - save money and use a commercial CA. Before spending any money on a commercial CA - look at alternatives such as Let's Encrypt. I am also looking at http://www.cacert.org/ (That might be something for you Ralph!)
thanks,
V
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 18 Aug 2017, voytek@sbt.net.au wrote:
BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ?
As Michael wrote already, it's the same vor all SSL certificates, because the underlying mechanism is the same.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEVAwUBWZakenz1H7kL/d9rAQLV7ggAqgiz+7ttcsu4/JAHExarvu+aovhNk+Lp OqzdlME8tSnEzKUfeHmkgXR2AMAOiET4HvsU0HWsm9zwyZ24Lgxo+mJ2lN6317H2 /nlNuQDImgDB8BLTarUpucVpp7R2ppXeuy+8TPyAmagZo6kR8okkFHoMzQSDHleG gPjoBDVHq0FH6WYq25u2ts7l6L+FKEinX5T/b2hcIqnTgM129E/ak1gYZWmQm9+S bM29aHNnpV/B8uPhACXruTV3DFWW2s9wIgopgHKA0XH4g7p3DYeiXFUTyZ+e9kNN oabc56sQSd4QASpEBjsOPd8Sx3pZtiXzxZnb3yLIhjyCilwNLZA8xw== =Phs1 -----END PGP SIGNATURE-----
On 18/08/2017 17:12, voytek@sbt.net.au wrote:
BUT, for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ?
(I'm currently using self issued for both mail and web)
thanks,
V
It depends on what you're uses are, self signed certs are OK for smtp/pop3/imap, since most people are just concerned with "encryption" in that case, but a different story if its web content, in particular, shopping carts and the like, If you have clients content, definitely use a real cert, maybe in 10 years letsencrypt might make the grade, but until every bit of software and OS supports it and they offer insurance levels like the bi boys do, you might as well be using a self signed cert, comodo are pretty cheap with basic insurance level on even the most basic of their offerings. Do your research, though if using a paid service, since some others are soon to be un-trusted.
-- Kind Regards,
Noel Butler
This Email, including any attachments, may contain legally privilegedinformation, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF [1] and ODF [2] documents accepted, please do not send proprietary formatted documents
Links:
[1] http://www.adobe.com/ [2] http://en.wikipedia.org/wiki/OpenDocument
On 18.08.2017 09:12, voytek@sbt.net.au wrote:
for a public web server where https is becoming mandatory, I'd still need a certificate from a recognized publisher, to avoid users geting 'warnings', is that so ?
For a certificate to be reported as "valid", an unbroken chain of cryptographic signatures is required. Browsers are released with a set of Root CA and Intermediate CA certificates, as are operating systems. Some use the Mozilla CA Certificate Store[1], for example, others come with their own CA stores, like macOS[2].
[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs... [2] https://support.apple.com/en-us/HT202858
Unless your web server certificate's signature chain originates from one of the CAs delivered with a web browser or OS, the end user connecting to your site will either have to manually add the required CAs, or add your server certificate, or be presented with a warning/error message.
One could argue that relying on certificate stores is placing personal security concerns in other people's hands. Of course, it would be a potentially funny thing to try and verify the validity of your online banking server's certificate by asking them to send you a letter containing the certificate fingerprint...
-Ralph
SvK> On Wed, 9 Aug 2017 08:39:30 -0700 SvK> Gregory Sloop <gregs@sloop.net> wrote:
AV> So i’m using dovecot, and i created a self signed certificate AV> with mkcert.sh based on dovecot-openssl.cnf. The name in there matches AV> my mail server.
AV> The first time it connects in mac mail however, it says the AV> certificate is invalid and another server might pretend to be me etc.
AV> I then have the option of trusting it.
AV> Is this normal behaviour? Will it always be invalid if it’s not signed AV> by a third party?
Yes. The point of a trusted CA signing your cert is that they have steps to "verify" who you are and that you're "authorized" to issue certs for the listed FQDNs. Without that, ANYONE could create a cert, and sign it and then present it to people connecting to your mail server [perhaps using a MITM style attack.] The connecting party would have no way to tell if your cert vs the attackers cert was actually valid.
It would be like showing up at the bank and having this exchange:
You: "Hey, I'm Jim Bob - can I take money out of his account?" Bank: "Do you have some ID?" You: "Yeah! See, I have this plastic card with my picture and name, that I ginned up in the basement."
Now does the bank say: "Yeah, that looks fine." or do they say "You know we really need ID [a certificate] that's authenticated and issued [signed] by the state [third-party/trusted CA.]."
I think it's obvious that accepting your basement produced ID would be a problem. [Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]
The alternative would be to add your CA cert [the one you signed the server cert with] to all the connecting clients as a trusted CA. This way your self signed cert would now be "trusted."
[The details are left as an exercise to the reader. Google is your friend.]
-Greg
SvK> This was exactly the global thinking - until the day DigiNotar fell. SvK> Since that day everybody should be aware that the true problem of a SvK> certificate is not its issuer, but the "trusted" third party CA. SvK> This could have been known way before of course by simply thinking about the SvK> basics. Do you really think your certificate gets more trustworthy because SvK> some guys from South Africa (just an example) say it is correct, running a SvK> _business_? Honestly, that is just naive. SvK> It would be far better to use a self-signed certificate that can be checked SvK> through some instance/host set inside your domain. Because only then the only SvK> one being responsible and trustworthy is yourself. And that is the way it SvK> should be. SvK> Everything else involving third party business is just bogus.
I'm really not interested in hashing out this argument - it's endless [we might as well discuss religion or politics too, while we're at it] - but I will address a couple of points.
- You'll note that I *specifically* noted "[Even if we also admit that while the state issued ID (or trusted CA signed certs) has some additional value, it isn't without potential flaws, etc.]"
Clearly there *are* issues with trusted CA's. But they also offer some value you can't get with a self-signed cert - especially to people who would connect to your servers, but who have no real relationship with you and thus no reason to have any trust for you or your certificates.
- Certificate revocation is a another very tricky situation where a self signed certificate system struggles.
So, in summary: the trusted CA's and their certificate "authentication" have some problems [perhaps more than some] - but also offer some benefits in spite of those problems. IMO, it's incredibly naive to say "would be far better to use a self-signed certificate..." - sure there might be some areas where it's better, but many others where it's not. It's not an "all good" or "all bad" kind of thing. As they say - the only secure computer is one encased in concrete at at the bottom of the deepest ocean trench, unpluged and unconnected - and even then I'm not completely sure.
Everything in life and security is a trade off of one set of factors against another.
Cheers! -Greg
On Thu, 10 Aug 2017 07:53:16 -0700 Gregory Sloop <gregs@sloop.net> wrote:
[...] Clearly there *are* issues with trusted CA's. But they also offer some value you can't get with a self-signed cert - especially to people who would connect to your servers, but who have no real relationship with you and thus no reason to have any trust for you or your certificates. [...] Cheers! -Greg
Let me drop all the rest and concentrate on this idea of yours. You really do mean that someone not trusting the issuer of some web site is _protected_ iff this very web uses a certificate from a trusted CA? How should that work out? If someone does not trust me or my certificate he should not use my web at all. The signed-by-CA certificate will not improve the content of the web (or other service) and therefore would be a fake security component anyway if I'd like to harm the visitor somehow. What kind of an argument is this? Really, the quality of the protected service is not linked in any way to the used certificate.
-- Regards, Stephan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Just my humble opinion:
We had ran a self-signed CA several years.
I would claim, that in theory this is more secure than using pre-installed third party CAs. Using a self-signed cert per server might do for small numers as well. However, when it comes to user divergence (or users coming from a wide range of knowledge and a wide range of devices come into play), roll your own is nightmare of support. As stated by others, some clients (Web browser, systems, mail clients, ...) make it hard to install own certs, Android even claims that the network (all of it from the interpretation of users) becomes insecure, once you install your own root cert. It looks like that more and more clients warns *each* time you access a server with a self-signed cert.
In the end, the gain of security (identify servers) was torpedoed by support and lack of understanding *and* will, even including poeple one might think they understand the need of extra steps in favour of security.
IMHO, the cert hierarchie today exclude eavesdropping by normal attackers, but is not suitable to identify servers or clients, because you (aka I) cannot trust the pre-installed trusted CAs.
If your set of users and devices is small enough, you can prepare all devices or offer an installation packet (for home users with a fixed set of clients), roll your own CA is easy and I would go this way. Alas, clients *should* mark personally trusted CAs differently than vendor-trusted ones. So users can see, if they speak with the correct server or if the server just looks alike, e.g. example.com vs. exampel.com .
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEVAwUBWY1RBHz1H7kL/d9rAQJQdAf/WgD+230Fon0rlXHeTsaQ2fZnn55yA+Eb 6K8RxEJ3y1EK6kgVAlAICxU92ft8smjQZGUU4vhWv/fLnXUErSaptOnXu3Nk7io2 5LqEwv+jmcLWthqxkSY2NJw3kzaNTYLcuQ8cXAVHuzwQlJO4x0MAq1WR4kVQtQh6 cP/EinFxhWjyqQElSJ7ph3EYR/UJVTx1HVFS6bBiA+vY9s07EH64SRomOSwVC3ng ryQZrwc2+5u+9hFfOnuGnBqj76szjhqPpa2PV7fQx8cFuJpJrctVxT+zbLf2sJpF 2XDzygpEiEbQuMe1st6ugOey9N+pdRWstsouVBbUAZ3L5PckmUYYVQ== =X902 -----END PGP SIGNATURE-----
On 09.08.2017 17:20, Alef Veld wrote:
So i’m using dovecot, and i created a self signed certificate with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
The first time it connects in mac mail however, it says the certificate is invalid and another server might pretend to be me etc.
This is to be expected for self-signed certificates. The MUA (Apple Mail in your case) cannot know that the certificate is trusted until you confirm it.
For certificates signed by third parties, the client (or OS) performs the same checks. If a chain of trust can be established based on the client/OS certificate store, which comes pre-populated with well-known third party CA certificates, allowing to verify certificate signatures, your MUA will trust the presented certificate without you confirming it.
I recommend you look into using a free Let's Encrypt certificate (see https://letsencrypt.org/) instead of a self-signed certificate.
-Ralph
Thanks Ralph, i’ll look into that.
I think let’s encrypt uses certbot though and it can’t do email certificates (although i’m sure i can convert the cert i get from let’s encrypt, i’ll look into it.
On 9 Aug 2017, at 16:40, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 09.08.2017 17:20, Alef Veld wrote:
So i’m using dovecot, and i created a self signed certificate with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
The first time it connects in mac mail however, it says the certificate is invalid and another server might pretend to be me etc.
This is to be expected for self-signed certificates. The MUA (Apple Mail in your case) cannot know that the certificate is trusted until you confirm it.
For certificates signed by third parties, the client (or OS) performs the same checks. If a chain of trust can be established based on the client/OS certificate store, which comes pre-populated with well-known third party CA certificates, allowing to verify certificate signatures, your MUA will trust the presented certificate without you confirming it.
I recommend you look into using a free Let's Encrypt certificate (see https://letsencrypt.org/) instead of a self-signed certificate.
-Ralph
Alef,
Certbot creates regular certificates that can be used by dovecot to get a “validated” connection to the mailserver. You obviously need to do the certbot walk to gain the certificate, but if you have it, you can use it for dovecot.
Just refer to it in the configuration and you should be fine..
Cheers Remko
On 9 Aug 2017, at 17:49, Alef Veld <alefveld@outlook.com> wrote:
Thanks Ralph, i’ll look into that.
I think let’s encrypt uses certbot though and it can’t do email certificates (although i’m sure i can convert the cert i get from let’s encrypt, i’ll look into it.
On 9 Aug 2017, at 16:40, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 09.08.2017 17:20, Alef Veld wrote:
So i’m using dovecot, and i created a self signed certificate with mkcert.sh based on dovecot-openssl.cnf. The name in there matches my mail server.
The first time it connects in mac mail however, it says the certificate is invalid and another server might pretend to be me etc.
This is to be expected for self-signed certificates. The MUA (Apple Mail in your case) cannot know that the certificate is trusted until you confirm it.
For certificates signed by third parties, the client (or OS) performs the same checks. If a chain of trust can be established based on the client/OS certificate store, which comes pre-populated with well-known third party CA certificates, allowing to verify certificate signatures, your MUA will trust the presented certificate without you confirming it.
I recommend you look into using a free Let's Encrypt certificate (see https://letsencrypt.org/) instead of a self-signed certificate.
-Ralph
On 09.08.2017 17:49, Alef Veld wrote:
I think let’s encrypt uses certbot though and it can’t do email certificates (although i’m sure i can convert the cert i get from let’s encrypt, i’ll look into it.
I'm not sure what you mean by "can’t do email certificates"? In any case, Let's Encrypt issues certificates that can be used by Dovecot for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix for SMTP. The certificates are issued for servers, not for specific software or protocols.
-Ralph
Cheers Remko and Ralph. I think there was some mention in the lets encrypt FAQ that certbot doesn't do email.
But I understand I can use their generated very for dovecot, postfix and https? That would be good indeed.
Anyone know of any manual, or can I just replace the certs in the dovecot and postfix locations with theirs? Do dovecot, postfix and apache all support .pem format?
Sent from my iPhone
On 9 Aug 2017, at 17:07, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 09.08.2017 17:49, Alef Veld wrote:
I think let’s encrypt uses certbot though and it can’t do email certificates (although i’m sure i can convert the cert i get from let’s encrypt, i’ll look into it.
I'm not sure what you mean by "can’t do email certificates"? In any case, Let's Encrypt issues certificates that can be used by Dovecot for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix for SMTP. The certificates are issued for servers, not for specific software or protocols.
-Ralph
Yes, yes, and yes.
This is what I do for https://webmail.lerctr.org, imap.lerctr.org, smtp.lerctr.org, et al.
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 8/9/17, 11:19 AM, "dovecot on behalf of Alef Veld" <dovecot-bounces@dovecot.org on behalf of alefveld@outlook.com> wrote:
Cheers Remko and Ralph. I think there was some mention in the lets encrypt FAQ that certbot doesn't do email.
But I understand I can use their generated very for dovecot, postfix and https? That would be good indeed.
Anyone know of any manual, or can I just replace the certs in the dovecot and postfix locations with theirs? Do dovecot, postfix and apache all support .pem format?
Sent from my iPhone
> On 9 Aug 2017, at 17:07, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
>
>> On 09.08.2017 17:49, Alef Veld wrote:
>>
>> I think let’s encrypt uses certbot though and it can’t do email
>> certificates (although i’m sure i can convert the cert i get from
>> let’s encrypt, i’ll look into it.
>
> I'm not sure what you mean by "can’t do email certificates"? In any
> case, Let's Encrypt issues certificates that can be used by Dovecot
> for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix
> for SMTP. The certificates are issued for servers, not for specific
> software or protocols.
>
> -RalphGreat, i’ll try that out.
On 9 Aug 2017, at 17:20, Larry Rosenman <larryrtx@gmail.com> wrote:
Yes, yes, and yes.
This is what I do for https://webmail.lerctr.org, imap.lerctr.org, smtp.lerctr.org, et al.
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: larryrtx@gmail.com US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
On 8/9/17, 11:19 AM, "dovecot on behalf of Alef Veld" <dovecot-bounces@dovecot.org on behalf of alefveld@outlook.com> wrote:
Cheers Remko and Ralph. I think there was some mention in the lets encrypt FAQ that certbot doesn't do email.
But I understand I can use their generated very for dovecot, postfix and https? That would be good indeed.
Anyone know of any manual, or can I just replace the certs in the dovecot and postfix locations with theirs? Do dovecot, postfix and apache all support .pem format?
Sent from my iPhone
On 9 Aug 2017, at 17:07, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 09.08.2017 17:49, Alef Veld wrote:
I think let’s encrypt uses certbot though and it can’t do email certificates (although i’m sure i can convert the cert i get from let’s encrypt, i’ll look into it.
I'm not sure what you mean by "can’t do email certificates"? In any case, Let's Encrypt issues certificates that can be used by Dovecot for IMAP and simultaneously by Apache or nginx for HTTPS and Postfix for SMTP. The certificates are issued for servers, not for specific software or protocols.
-Ralph
On 09.08.2017 18:18, Alef Veld wrote:
Anyone know of any manual, or can I just replace the certs in the dovecot and postfix locations with theirs? Do dovecot, postfix and apache all support .pem format?
Google "dovecot letsencrypt" is your friend. ;-) If you have questions about details, we can discuss them of course. Also, please limit your replies to my messages to the mailing list; you keep triggering my spam protection.
-Ralph
Thank you Ralph. I’ll have a look around myself first, don’t want others to waste their time on my homework.
Sorry for some reason i get replies from every individual , so when i reply it sends it to both. I would expect replies to come from dovecot@dovecot.org as well.
I will strip the individual emails out and just reply to dovecot.
On 9 Aug 2017, at 17:30, Ralph Seichter <m16+dovecot@monksofcool.net> wrote:
On 09.08.2017 18:18, Alef Veld wrote:
Anyone know of any manual, or can I just replace the certs in the dovecot and postfix locations with theirs? Do dovecot, postfix and apache all support .pem format?
Google "dovecot letsencrypt" is your friend. ;-) If you have questions about details, we can discuss them of course. Also, please limit your replies to my messages to the mailing list; you keep triggering my spam protection.
-Ralph
participants (14)
-
Alef Veld
-
Doug Hardie
-
Florian Beer
-
Frank-Ulrich Sommer
-
Gregory Sloop
-
Larry Rosenman
-
Michael Felt
-
Noel Butler
-
Ralph Seichter
-
Remko Lodder
-
Ruben Safir
-
Steffen Kaiser
-
Stephan von Krawczynski
-
voytek＠sbt.net.au