Quantcast

Re: Need help with TLS keys...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help with TLS keys...

Michael Segel
Sorry this hit my junkmail folder…


The fix to this was to turn off SELinux.
Everytime the smtpd daemon tried to read the cert, it would get denied.
Once I turned off SELinux… it was happy.

(Of course the cert is 8192 which may be a bit excessive over 2048)  

-Mike

> On Apr 20, 2017, at 2:41 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>
>> On Apr 20, 2017, at 2:48 PM, Michael Segel <[hidden email]> wrote:
>>
>> warning: cannot get RSA certificate from file /etc/pki/dovecot/mailCert.pem: disabling TLS support
>
> That means that the file contained no certificate and/or was corrupted.
> Additional messages may be logged following that one with more detail if
> the file could not be parsed.
>
> There are many certificate formats, when you say "cert", what format are
> you using?
>
> If you have SELinux or similar, the security software may be preventing
> Postfix (even when running as "root") from reading the file.
>
>> The first time I tried this was to set up the cert and key (private) in to two different files and then place them in the /etc/pki/dovecot/certs and ../private folders.  Both were 644 and I had this error.
>
> The private key should not be world-readable.
>
>> I tried to follow some of the advice online, and one of them suggested that I combine the two in to a single file, and then check them (I did) and then have postfix point to that file for either the cert or the key.
>
> A single mode 0600 file is sometimes simpler, but separate files are equally
> well supported.
>
>> I tested the three files to ensure that the key and the cert were valid
>> and ran both tests on the combined file.
>
> That means nothing when you don't explain in detail what tests you ran.
>
>> Is there a maximum size to the key?
>
> Some TLS implementations limit the key size.  And ridiculously large keys
> may therefore not interoperate.
>
>> I know it defaults to 2048, but I bumped it up to 8192.
>
> 8192 is ridiculously large.  You get less security when remote senders
> can't use the key, and fall back to cleartext.  Stick to 2048, and of
> course if you change the key you need a corresponding new certificate.
>
> --
> Viktor.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help with TLS keys...

Viktor Dukhovni

> On Apr 24, 2017, at 10:20 AM, Michael Segel <[hidden email]> wrote:
>
> (Of course the cert is 8192 which may be a bit excessive over 2048)  

Don't be a crypto fashionista.  Generate a 2048-bit key and obtain and
deploy a corresponding 2048-bit certificate.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help with TLS keys...

Michael Segel
I wouldn’t say fashionista…

More of an experiment since its easy to replace the tickets.
I wanted to try something a wee bit more secure.  There’s actually a downstream reason for this…


But of course, I’m still at a loss as to why the initial rDNS handshake as well as attempts to hit zen.spamhaus for a lookup are also failing.

Could it be a firewall port that I have blocked? I’m not sure how Postfix is doing the initial rDNS lookup to validate hostname.


> On Apr 24, 2017, at 11:40 AM, Viktor Dukhovni <[hidden email]> wrote:
>
>
>> On Apr 24, 2017, at 10:20 AM, Michael Segel <[hidden email]> wrote:
>>
>> (Of course the cert is 8192 which may be a bit excessive over 2048)  
>
> Don't be a crypto fashionista.  Generate a 2048-bit key and obtain and
> deploy a corresponding 2048-bit certificate.
>
> --
> Viktor.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help with TLS keys...

Viktor Dukhovni

> On Apr 24, 2017, at 12:51 PM, Michael Segel <[hidden email]> wrote:
>
> I wouldn’t say fashionista…
>
> More of an experiment since its easy to replace the tickets.
> I wanted to try something a wee bit more secure.  There’s actually a downstream reason for this…

Excessively long keys that exceed the needs of nation state agencies and reduce
interoperability are not "a wee bit more secure".  Especially with opportunistic
security, these yield less security, not more.

> But of course, I’m still at a loss as to why the initial rDNS handshake as well
> as attempts to hit zen.spamhaus for a lookup are also failing.

DNS requests for SpamHaus cannot be forwarded to an ISP resolver.  As explained
multiple times, you need to run your own resolver and list only that resolver
(127.0.0.1) in /etc/resolv.conf.

Also disable chroot at least long enough to get your system working.  Then, if
you feel confident you know how to operate a working chroot environment, enable
chroot for some services and test with care.  For most users chroot is not worth
it.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need help with TLS keys...

Michael Segel

> On Apr 24, 2017, at 12:15 PM, Viktor Dukhovni <[hidden email]> wrote:
>
>
>> On Apr 24, 2017, at 12:51 PM, Michael Segel <[hidden email]> wrote:
>>
>> I wouldn’t say fashionista…
>>
>> More of an experiment since its easy to replace the tickets.
>> I wanted to try something a wee bit more secure.  There’s actually a downstream reason for this…
>
> Excessively long keys that exceed the needs of nation state agencies and reduce
> interoperability are not "a wee bit more secure".  Especially with opportunistic
> security, these yield less security, not more.
>

>> But of course, I’m still at a loss as to why the initial rDNS handshake as well
>> as attempts to hit zen.spamhaus for a lookup are also failing.
>
> DNS requests for SpamHaus cannot be forwarded to an ISP resolver.  As explained
> multiple times, you need to run your own resolver and list only that resolver
> (127.0.0.1) in /etc/resolv.conf.
>
I will have to check how I’m doing it on my other server.
It works there but not on the new machine.

Both should be roughly the same although the older server is Centos 6 and an earlier version of postfix and dovecot.

> Also disable chroot at least long enough to get your system working.  Then, if
> you feel confident you know how to operate a working chroot environment, enable
> chroot for some services and test with care.  For most users chroot is not worth
> it.
>
> --
> Viktor.
>

Loading...