[Dovecot] Changing SSL certificates - switching from self-signed to RapidSSL
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Until now, we've been using self-signed certs with the following dovecot config:
ssl = required ssl_cert =
Now, I've created new keys/certs and the CSR, got the new certs from RapidSSL (and also downloaded their Intermediate bundle), saved everything per their instructions, which say to reference them as follows:
ssl = required ssl_cert_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca_file = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
But my current config doesn't have the _file for the variable names, and the wiki doesn't use them, so I'm planning on setting these to:
ssl = required ssl_cert = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
Anyone else ever used RapidSSL certs? Does this look correct?
Thanks,
Charles
On 18/04/2014 1:57 PM, Charles Marcus wrote:
But my current config doesn't have the _file for the variable names, and the wiki doesn't use them, so I'm planning on setting these to:
ssl = required ssl_cert = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
http://wiki2.dovecot.org/SSL/DovecotConfiguration Note "Chained SSL certificates" section
18.04.2014 19:57, Charles Marcus:
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Until now, we've been using self-signed certs with the following dovecot config:
ssl = required ssl_cert =
Now, I've created new keys/certs and the CSR, got the new certs from RapidSSL (and also downloaded their Intermediate bundle), saved everything per their instructions, which say to reference them as follows:
ssl = required ssl_cert_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca_file = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
But my current config doesn't have the _file for the variable names, and the wiki doesn't use them, so I'm planning on setting these to:
ssl = required ssl_cert = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
Anyone else ever used RapidSSL certs? Does this look correct?
Yes. No. Aside from the missing indirection (use ... =
Instead, cat your new server certificate together with the CA certificates into one file and point ssl_cert to this file (see "Chained SSL certificates" in http://wiki2.dovecot.org/SSL/DovecotConfiguration ).
-- Regards mks
Thanks Markus and Oscar...
On 4/18/2014 3:29 PM, Markus Schönhaber dovecot@list-post.mks-mail.de wrote:
Aside from the missing indirection (use ... =
Yeah, the < was in the config, dunno how it got stripped from my post - or maybe I manually typed those - yeah, I think I did...
Instead, cat your new server certificate together with the CA certificates into one file and point ssl_cert to this file (see "Chained SSL certificates" in http://wiki2.dovecot.org/SSL/DovecotConfiguration ).
Ok, did that and made the config change and restarted dovecot.
Everything seems to be working, BUT... I'm now seeing some of these errors, that were not showing up in the logs before:
2014-04-18T15:42:24-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=24.126.163.180, lport=143 2014-04-18T15:42:34-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=98.66.176.115, lport=143
!2 total in the last 25 minutes since flipping the switch.
and there have been two of these:
2014-04-18T15:54:07-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=99.14.24.224, lport=143
Not a huge number, but enough to be concerning...
Could this just be from cached junk from some clients, and they will resolve themselves over time?
--
Best regards,
Charles Marcus I.T. Director Media Brokers International, Inc. 678.514.6224 | 678.514.6299 fax
On 4/18/2014 3:57 PM, Charles Marcus CMarcus@Media-Brokers.com wrote:
Everything seems to be working, BUT... I'm now seeing some of these errors, that were not showing up in the logs before:
2014-04-18T15:42:24-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=24.126.163.180, lport=143 2014-04-18T15:42:34-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=98.66.176.115, lport=143
!2 total in the last 25 minutes since flipping the switch.
and there have been two of these:
2014-04-18T15:54:07-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=99.14.24.224, lport=143
Not a huge number, but enough to be concerning...
Ahh... I'm sure we have some older clients that are still configured to use a different hostname...
So, if the new certs are for mail.example.com, and a client tries to connect using a different hostname, like imap.example.com, would that result in these kinds of errors?
18.04.2014 22:12, Charles Marcus:
On 4/18/2014 3:57 PM, Charles Marcus CMarcus@Media-Brokers.com wrote:
Everything seems to be working, BUT... I'm now seeing some of these errors, that were not showing up in the logs before:
2014-04-18T15:42:24-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=24.126.163.180, lport=143 2014-04-18T15:42:34-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS: SSL_read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=98.66.176.115, lport=143
!2 total in the last 25 minutes since flipping the switch.
and there have been two of these:
2014-04-18T15:54:07-04:00 dinkumthinkum dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, rip=99.14.24.224, lport=143
Not a huge number, but enough to be concerning...
Ahh... I'm sure we have some older clients that are still configured to use a different hostname...
So, if the new certs are for mail.example.com, and a client tries to connect using a different hostname, like imap.example.com, would that result in these kinds of errors?
The errors indicate that a client didn't like your certificate for some reason. One of the possible reasons surely is a CN in the certificate that doesn't match the name of the server the client thinks he's connecting to.
So the answer to your question is very likely "yes".
-- Regards mks
On 4/18/2014 4:41 PM, Markus Schönhaber dovecot@list-post.mks-mail.de wrote:
The errors indicate that a client didn't like your certificate for some reason. One of the possible reasons surely is a CN in the certificate that doesn't match the name of the server the client thinks he's connecting to. So the answer to your question is very likely "yes".
Thanks for the confirmation...
I'm think I'm going to simply remove that DNS entry and deal with a few support phone calls...
--
Best regards,
Charles Marcus I.T. Director Media Brokers International, Inc. 678.514.6224 | 678.514.6299 fax
Am 18.04.2014 22:12, schrieb Charles Marcus:
Ahh... I'm sure we have some older clients that are still configured to use a different hostname...
So, if the new certs are for mail.example.com, and a client tries to connect using a different hostname, like imap.example.com, would that result in these kinds of errors?
yes
and that is why nobody should provide more than one hostname for mailservers there is no gain and it ends where you are now
would you have not wasted the time for different DNS records instead just provide and communicate mail.your-primardy-domain.tld all the years before TLS now would be a no-brainer
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Until now, we've been using self-signed certs with the following dovecot config:
ssl = required ssl_cert =
Now, I've created new keys/certs and the CSR, got the new certs from RapidSSL (and also downloaded their Intermediate bundle), saved everything per their instructions, which say to reference them as follows:
ssl = required ssl_cert_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key_file = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca_file = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
But my current config doesn't have the _file for the variable names, and the wiki doesn't use them, so I'm planning on setting these to:
ssl = required ssl_cert = /etc/ssl/ourNewCerts/mail.ourdomain.com.crt ssl_key = /etc/ssl/ourNewCerts/mail.ourdomain.com.key ssl_ca = /etc/ssl/ourNewCerts/RapidSSL_Intermediate.crt
Anyone else ever used RapidSSL certs? Does this look correct? Hi Charles,
Il 18/04/2014 19:57, Charles Marcus ha scritto: the RapidSSL documentation is wrong:
- as you noted, you should use "ssl_cert" instead of "ssl_cert_file", and so on;
- the file paths should be prefixed by "<", otherwise Dovecot will not read the files;
- the "ssl_ca" setting is *not* used to make Dovecot reference intermediate certificates in the trust chain - it is used to specify trusted CAs in case you want to perform TLS client certificate authentication, which I suppose you do not want to do.
You should:
- make a backup copy of /etc/ssl/ourNewCerts/mail.ourdomain.com.crt;
- open /etc/ssl/ourNewCerts/mail.ourdomain.com.crt and, at the end of the file, paste the contents of /etc/ssl/ourNewCerts /RapidSSL_Intermediate.crt; in the end, /etc/ssl/ourNewCerts /mail.ourdomain.com.crt should contain the certificate for mail.ourdomain.com and the intermediate RapidSSL certificate (in that order);
- use the following settings: ssl = required ssl_cert =
where "mail.ourdomain.com.crt" contains the two certificates as
# explained above ssl_key =
Hope this helps, Alessandro Menti
On 4/18/2014 3:32 PM, Alessandro Menti alessandro.menti@hotmail.it wrote:
- open /etc/ssl/ourNewCerts/mail.ourdomain.com.crt and, at the end of the file, paste the contents of /etc/ssl/ourNewCerts /RapidSSL_Intermediate.crt; in the end, /etc/ssl/ourNewCerts /mail.ourdomain.com.crt should contain the certificate for mail.ourdomain.com and the intermediate RapidSSL certificate (in that order);
The Intermediate file already contained 2 certs... so, after I added it to mine, it now contains 3 certs...
Is that right?
Thanks, I appreciate the help...
Il 18/04/2014 22:08, Charles Marcus ha scritto:
On 4/18/2014 3:32 PM, Alessandro Menti alessandro.menti@hotmail.it wrote:
- open /etc/ssl/ourNewCerts/mail.ourdomain.com.crt and, at the end of the file, paste the contents of /etc/ssl/ourNewCerts /RapidSSL_Intermediate.crt; in the end, /etc/ssl/ourNewCerts /mail.ourdomain.com.crt should contain the certificate for mail.ourdomain.com and the intermediate RapidSSL certificate (in that order);
The Intermediate file already contained 2 certs... so, after I added it to mine, it now contains 3 certs...
Is that right? That's right.
Regards, Alessandro Menti
On Fri, 18 Apr 2014 13:57:47 -0400 Charles Marcus CMarcus@Media-Brokers.com wrote:
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Well, I guess one has to tell you that: probably nobody will be informed, because the company is dead afterwards (just
- No certs no matter if self-signed or not would have saved you from heartbleed.
- "real certs" issued from cert-dealers are no more safe than your self-signed was. In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time
like diginotar). In fact the whole cert business is a big fake currently. 3) The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole.
-- Regards, Stephan
Am 19.04.2014 09:14, schrieb Stephan von Krawczynski:
On Fri, 18 Apr 2014 13:57:47 -0400 Charles Marcus CMarcus@Media-Brokers.com wrote:
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Well, I guess one has to tell you that:
- No certs no matter if self-signed or not would have saved you from heartbleed
yes, but you seem not to understand hat "Heartbleed" is the moment which you can use to say "now let us take SSL serious" in general as well as other security topics because *now* you can point somewehere and say "look manager, things happening in real"
- "real certs" issued from cert-dealers are no more safe than your self-signed was. In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time probably nobody will be informed, because the company is dead afterwards (just like diginotar). In fact the whole cert business is a big fake currently
yes but you can't change that nor can i
- The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole.
bulls**t because you can't do that if your mailusers are ordianary customers and even if you get managed that they import your self signed cert that *does not* change the fact that they get no alert in case of a MITM attack presenting whatever certificate signed from a CA all clients are trusting
without certificate pinning you are lost in any case and with certificate pinning you can avoid the inital warning nobody of the ordinary users understands - so until you come with a solution for certificate pinning on and endusers MUA better don't explain things anybody knows
On Sat, 19 Apr 2014 09:22:07 +0200 Reindl Harald h.reindl@thelounge.net wrote:
Am 19.04.2014 09:14, schrieb Stephan von Krawczynski:
On Fri, 18 Apr 2014 13:57:47 -0400 Charles Marcus CMarcus@Media-Brokers.com wrote:
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs...
Well, I guess one has to tell you that:
- No certs no matter if self-signed or not would have saved you from heartbleed
yes, but you seem not to understand hat "Heartbleed" is the moment which you can use to say "now let us take SSL serious" in general as well as other security topics because *now* you can point somewehere and say "look manager, things happening in real"
Yes, but all he has to do is ask you if this problem would have arised if he had a "real cert" to know that your spending money would not have helped.
- "real certs" issued from cert-dealers are no more safe than your self-signed was. In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time probably nobody will be informed, because the company is dead afterwards (just like diginotar). In fact the whole cert business is a big fake currently
yes but you can't change that nor can i
So you say: "better fake security than no security" ?
- The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole.
bulls**t because you can't do that if your mailusers are ordianary customers and even if you get managed that they import your self signed cert that *does not* change the fact that they get no alert in case of a MITM attack presenting whatever certificate signed from a CA all clients are trusting
without certificate pinning you are lost in any case and with certificate pinning you can avoid the inital warning nobody of the ordinary users understands - so until you come with a solution for certificate pinning on and endusers MUA better don't explain things anybody knows
It does not matter if you can do something _now_ or not. The only way to improve a not working situation is to tell that it is not working (my way) and not to ignore it (your way).
-- Regards, Stephan
Am 19.04.2014 09:30, schrieb Stephan von Krawczynski:
On Sat, 19 Apr 2014 09:22:07 +0200 Reindl Harald h.reindl@thelounge.net wrote:
yes, but you seem not to understand hat "Heartbleed" is the moment which you can use to say "now let us take SSL serious" in general as well as other security topics because *now* you can point somewehere and say "look manager, things happening in real"
Yes, but all he has to do is ask you if this problem would have arised if he had a "real cert" to know that your spending money would not have helped.
and then i would explain him: no but we don't waste additional time because every customer makes a support call after we change the self signed certificate and all mail-clients out there alerting
- "real certs" issued from cert-dealers are no more safe than your self-signed was. In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time probably nobody will be informed, because the company is dead afterwards (just like diginotar). In fact the whole cert business is a big fake currently
yes but you can't change that nor can i
So you say: "better fake security than no security"?
no - you need to understand that SSL has *two* goals
- encyrption
- authentication
encryption works independent of authentication authentication is fucked up in general and broken by design and because that it's not worth to waste time explain users over and over how to accept the self-signed one while you do a big harm with that: train monkeys to ignore warnings
but that does not change the main-goal: encryption
- The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole.
bulls**t because you can't do that if your mailusers are ordianary customers and even if you get managed that they import your self signed cert that *does not* change the fact that they get no alert in case of a MITM attack presenting whatever certificate signed from a CA all clients are trusting
without certificate pinning you are lost in any case and with certificate pinning you can avoid the inital warning nobody of the ordinary users understands - so until you come with a solution for certificate pinning on and endusers MUA better don't explain things anybody knows
It does not matter if you can do something _now_ or not. The only way to improve a not working situation is to tell that it is not working (my way) and not to ignore it (your way)
it is working, it is working as good as it can and if you compare the costs of 130 € for 3 years with support calls because self signed certificates and do a *real harm* by train ordinary users to ignore warnings just guess which way works
honestly if i connect to a server owned by a company coming with a self-signed certificate without got told so before i get alarmed that they may not be trustworthy because if they save the little money for the cert i may assume they save money on other important things too
On Sat, 19 Apr 2014 09:40:07 +0200 Reindl Harald h.reindl@thelounge.net wrote:
it is working, it is working as good as it can and if you compare the costs of 130 € for 3 years with support calls because self signed certificates and do a *real harm* by train ordinary users to ignore warnings just guess which way works
honestly if i connect to a server owned by a company coming with a self-signed certificate without got told so before i get alarmed that they may not be trustworthy because if they save the little money for the cert i may assume they save money on other important things too
Honestly, with your awareness of "as good as it can" wouldn't it be fair to tell people that they spend millions all over the planet for something that is not working? How can you expect the situation to get any better if you cover the problem by buying certs only for the reason to avoid warnings that are useless anyways? You know things go wrong and still do support it. I think one should have learned in the after-Snowden-era where this leads to.
-- Regards, Stephan
Am 19.04.2014 09:58, schrieb Stephan von Krawczynski:
On Sat, 19 Apr 2014 09:40:07 +0200 Reindl Harald h.reindl@thelounge.net wrote:
it is working, it is working as good as it can and if you compare the costs of 130 € for 3 years with support calls because self signed certificates and do a *real harm* by train ordinary users to ignore warnings just guess which way works
honestly if i connect to a server owned by a company coming with a self-signed certificate without got told so before i get alarmed that they may not be trustworthy because if they save the little money for the cert i may assume they save money on other important things too
Honestly, with your awareness of "as good as it can" wouldn't it be fair to tell people that they spend millions all over the planet for something that is not working? How can you expect the situation to get any better if you cover the problem by buying certs only for the reason to avoid warnings that are useless anyways?
how can you expect it get's better by self signed certificates and train users to "ignore warnings because they are useless"
you can do that for your pet's homepage where you know any visitor in person but not for the world
what you achieve is they ignore all other warnings too because guys like you told them "warnings are useless"
You know things go wrong and still do support it. I think one should have learned in the after-Snowden-era where this leads to
and where does it lead to trigger warnings all over the planet and train people to ignore them? in case of a mailserver that's not a real big problem because they amount of users is limited
on a public website it is insane to present a browser warning as welcome message
if there is a working replacement, widely supported by client-software and useable or the ordinary enduser - fine - let us adopt it - until that does not exist you are talking bullshit
well, i have an offer for you: you pay the support calls caused by certificate warnings, you pay also the harm of other ignored warnings as result of train monkeys, you go out and make *every* enduser to a tech person understand certificates and SSL before and after that we all start to drop CA certificates
deal?
On Sat, 19 Apr 2014 10:20:39 +0200 Reindl Harald h.reindl@thelounge.net wrote:
and where does it lead to trigger warnings all over the planet and train people to ignore them? in case of a mailserver that's not a real big problem because they amount of users is limited
on a public website it is insane to present a browser warning as welcome message
if there is a working replacement, widely supported by client-software and useable or the ordinary enduser - fine - let us adopt it - until that does not exist you are talking bullshit
well, i have an offer for you: you pay the support calls caused by certificate warnings, you pay also the harm of other ignored warnings as result of train monkeys, you go out and make *every* enduser to a tech person understand certificates and SSL before and after that we all start to drop CA certificates
deal?
So you like market behaviour. Don't you think that the market of client software will react faster if everybody is aware of the currently unsolved problems? My word is: make them aware. Your word is: safe money and give a damn. Lets stop it here, it is obvious we disagree and I guess people on the list have heard enough to take their own decisions.
-- Regards, Stephan
Am 19.04.2014 10:44, schrieb Stephan von Krawczynski:
On Sat, 19 Apr 2014 10:20:39 +0200 Reindl Harald h.reindl@thelounge.net wrote:
and where does it lead to trigger warnings all over the planet and train people to ignore them? in case of a mailserver that's not a real big problem because they amount of users is limited
on a public website it is insane to present a browser warning as welcome message
if there is a working replacement, widely supported by client-software and useable or the ordinary enduser - fine - let us adopt it - until that does not exist you are talking bullshit
well, i have an offer for you: you pay the support calls caused by certificate warnings, you pay also the harm of other ignored warnings as result of train monkeys, you go out and make *every* enduser to a tech person understand certificates and SSL before and after that we all start to drop CA certificates
deal?
So you like market behaviour
no, but after more than 11 years working in the IT as software developer and sysadmin building any admin backends, automation tools and cms-systems at my own while dealing with the endusers and their software i have learned which fights i can't win and better spend my time to work on things gaining a result
Don't you think that the market of client software will react faster if everybody is aware of the currently unsolved problems?
only in a perfect world
in the world i sadly live i had to turn SSL3 on again after a complaint of big customer that one of his customers can't use his shop with MSIE6 and is not willing to enable TLS in the settings which is one click i did 13 years ago in times using Windows, well now after Heartbleed and EOL of WiNXP now i had the arguments to disable it forever -> done
in the world i sadly live i had recently a customer using a 10 years old Eudora mail-client on MacOSX which don't work with SHA256 certificates - the reply to "please update your OS and your mail-client, this one is unsupported and higly insecure" was "but i was happy with it until *you* changed something"
My word is: make them aware
mine too, but make aware and try to force end-users to understand things are different worlds - you can't win the fight against users ignorance, careless and their outdated software
Your word is: safe money and give a damn
my word is safe time where it is wasted and use it to improve things in areas where i can win a fight - fighting a lost battle leads to nowehere and eats the time to improve other things
i spent hundrets of hours in security the last few years looking at a big picture of all sort of network services and operating systems to work as secure as possible with each other
if i would have wasted that time with lost battles i would have gained nothing
Lets stop it here, it is obvious we disagree and I guess people on the list have heard enough to take their own decisions
agreed
On 4/19/2014 3:30 AM, Stephan von Krawczynski skraw@ithnet.com wrote:
On Sat, 19 Apr 2014 09:22:07 +0200 Reindl Harald wrote:
Am 19.04.2014 09:14, schrieb Stephan von Krawczynski:
- "real certs" issued from cert-dealers are no more safe than your self-signed was.
yes but you can't change that nor can i
So you say: "better fake security than no security" ?
Don't be silly. It isn't 'fake security'. It obviously involves risks, but the security is real, as long as the chain isn't compromised.
The risk lies in the potential for the chain to be compromised.
--
Best regards,
Charles
Please Reply-To-List, don't send to me directly, I'm on the list.
On 4/19/2014 3:14 AM, Stephan von Krawczynski skraw@ithnet.com wrote:
On Fri, 18 Apr 2014 13:57:47 -0400 Charles Marcus CMarcus@Media-Brokers.com wrote:
Hi all,
Ok, been wanting to do this for a while, and I after the Heartbleed fiasco, the boss finally agreed to let me buy some real certs... Well, I guess one has to tell you that:
- No certs no matter if self-signed or not would have saved you from heartbleed.
I know that. I simply leveraged the noise to convince the boss to buy some real certs.
And NO, I did not suggest that having real certs would have made us immune (in fact I told him it wouldn't), but the fiasco was a good time to bring the subject up again (I've been trying for years to get him to let me buy real certs to avoid the scary warnings).
- "real certs" issued from cert-dealers are no more safe than your self-signed was.
I know this. I want 'real' certs so our users no longer the stupid big ugly scary warnings about untrusted certs when setting up mail clients.
In fact they add the risk of your cert-dealter being hacked and you don't know. _This has happened_ already for at least one cert-dealer. So there is no proof at all that it will not happen again and this time probably nobody will be informed, because the company is dead afterwards (just like diginotar).
All true, but there is risk in everything.
In fact the whole cert business is a big fake currently.
In theory I agree, but the reality is different from theory.
- The whole SSL stuff can only be made secure by implementing methods to authorize self-signed certs yourself and the clients using it being able to check that. Every checking by external "authorities" is just an uncontrollable security hole.
True, but running my own CA, and requiring users to follow complicated (for them) instructions oon how to install our own CA into all of their clients is simply not a viable option (for us).
--
Best regards,
Charles
participants (6)
-
Alessandro Menti
-
Charles Marcus
-
Markus Schönhaber
-
Oscar del Rio
-
Reindl Harald
-
Stephan von Krawczynski