SSL not working after unwanted server migration

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SSL not working after unwanted server migration

Marco Fioretti
Greetings,

I had my personal postfix/dovecot server, configured for some of my
own domains, running without problems on a linux VPS. For reasons
totally out of my control, I had to migrate everything to another VPS
two days ago, without notice, (details at the bottom if anybody is
interested...), and consequently without any possibility to do the due
homework and testing *BEFORE* the migration, so please be patient...

The problem: since software and operating system versions are not the
same as before, certain settings stopped working. So far the only
major one I can't handle myself, both in dovecot and postfix, seems to
be TLS/SSL configuration. I regenerated and installed a new SSL
certificate with letsencrypt, but:

- in dovecot, I can't connect because "ssl3_get_client_hello:no shared
cipher", no matter which ciphers I configure (I've already asked about
this on the dovecot list)

-  postfix receives email, but:
       - also gets lots of "454 4.7.0 TLS not available due to local
problem" connecting to google servers

       -  if I try to send email, I get this:

    Our system has detected that this message does
    550-5.7.1 not meet IPv6 sending guidelines regarding PTR
   records and  550-5.7.1 authentication. Please review...

As far as I can tell, this is a combination of postfix/dovecot
settings not valid anymore + wrong file/folder permissions + maybe not
compatible selinux (now set to "permissive"). I am already reading all
the online resources I can find, but I find no clear consensus on what
should be done. Any help is appreciated!

Thanks, and here is the postfix configuration:

I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.MYDOMAIN
mynetworks = 127.0.0.0/8, 212.110.184.219
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:5000
postconf: warning: /etc/postfix/main.cf: unused parameter:
smtp_tls_auth_only=yes
postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D


WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
that they were going out of business on Dec 8th. For several personal
reasons not relevant here (short version:  have simply been almost
unable to work in the same weeks) I only discovered this... on Dec.
8th.
I had no time at all to test anything. Saturday I bought a new VPS
from another provider, changed DNS records to point there, set up a
new SSL certificate with letsencrypt,  copied all the files and
mailboxes to the new VPS and only after that I was able to start
checking if configuration needed changes
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

rachalmers

Google is refusing access because your ipv6 PTR does not map to your domain.
It’s the common (now) google reverse lookup failing.


-----
Robert Chalmers
https://robert-chalmers.uk
[hidden email]
@R_A_Chalmers


On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:

Greetings,

I had my personal postfix/dovecot server, configured for some of my
own domains, running without problems on a linux VPS. For reasons
totally out of my control, I had to migrate everything to another VPS
two days ago, without notice, (details at the bottom if anybody is
interested...), and consequently without any possibility to do the due
homework and testing *BEFORE* the migration, so please be patient...

The problem: since software and operating system versions are not the
same as before, certain settings stopped working. So far the only
major one I can't handle myself, both in dovecot and postfix, seems to
be TLS/SSL configuration. I regenerated and installed a new SSL
certificate with letsencrypt, but:

- in dovecot, I can't connect because "ssl3_get_client_hello:no shared
cipher", no matter which ciphers I configure (I've already asked about
this on the dovecot list)

-  postfix receives email, but:
      - also gets lots of "454 4.7.0 TLS not available due to local
problem" connecting to google servers

      -  if I try to send email, I get this:

   Our system has detected that this message does
   550-5.7.1 not meet IPv6 sending guidelines regarding PTR
  records and  550-5.7.1 authentication. Please review...

As far as I can tell, this is a combination of postfix/dovecot
settings not valid anymore + wrong file/folder permissions + maybe not
compatible selinux (now set to "permissive"). I am already reading all
the online resources I can find, but I find no clear consensus on what
should be done. Any help is appreciated!

Thanks, and here is the postfix configuration:

I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost
mydomain = $myhostname
myhostname = a.mx.MYDOMAIN
mynetworks = 127.0.0.0/8, 212.110.184.219
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
procmail_destination_recipient_limit = 1
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
relay_domains =
sample_directory = /etc/postfix
sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sender_dependent_authentication = yes
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions =
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = reject_invalid_hostname,
reject_non_fqdn_hostname, reject_non_fqdn_sender,
reject_non_fqdn_recipient, reject_unknown_sender_domain,
reject_unknown_recipient_domain, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_helo_access hash:/etc/postfix/reject_own_helo,
check_policy_service unix:postgrey/socket
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
strict_rfc821_envelopes = yes
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/mail/mymail_storage
virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
virtual_transport = procmail
virtual_uid_maps = static:5000
postconf: warning: /etc/postfix/main.cf: unused parameter:
smtp_tls_auth_only=yes
postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D


WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
that they were going out of business on Dec 8th. For several personal
reasons not relevant here (short version:  have simply been almost
unable to work in the same weeks) I only discovered this... on Dec.
8th.
I had no time at all to test anything. Saturday I bought a new VPS
from another provider, changed DNS records to point there, set up a
new SSL certificate with letsencrypt,  copied all the files and
mailboxes to the new VPS and only after that I was able to start
checking if configuration needed changes
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Marco Fioretti
Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
<[hidden email]> ha scritto:

>
> Google is refusing access because your ipv6 PTR does not map to your domain.
> It’s the common (now) google reverse lookup failing.
> ...

thanks for the reminder.

I know, but had temporarily forgotten due to how that this migration
"crashed" on me
without notice, the need to have that mapping. I have already
contacted the provider
of the new VPS to handle this.

My doubts, and consequent need for help, about my postfix configuration remain,
however. I do *believe* that I have done everything correctly wrt generating and
installing letsencryptcertificates.

However, I know for a fact that TLS/SSL is not working in dovecot, am not
sure at all if the postfix TLS/SSL configuration is correct, or
complete, and I also am not sure if the interwork between dovecot and
postfix is configured correctly.

I have found several pages with contrasting advice on how to set file ownership/
permissions for the certificate files so postfix can access them, and if / how
selinux may have a part in theproblem (even if in my vps is set to "permissive"
right now).  So any further comment/check on my postconf -n output is still
very welcome (as I said, right now I am running postfix 2.10.1, while
the config files I am using are from a
2.5/2.6 installation, I do not remember exactly)

Thanks,
Marco





> On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:
>
> Greetings,
>
> I had my personal postfix/dovecot server, configured for some of my
> own domains, running without problems on a linux VPS. For reasons
> totally out of my control, I had to migrate everything to another VPS
> two days ago, without notice, (details at the bottom if anybody is
> interested...), and consequently without any possibility to do the due
> homework and testing *BEFORE* the migration, so please be patient...
>
> The problem: since software and operating system versions are not the
> same as before, certain settings stopped working. So far the only
> major one I can't handle myself, both in dovecot and postfix, seems to
> be TLS/SSL configuration. I regenerated and installed a new SSL
> certificate with letsencrypt, but:
>
> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared
> cipher", no matter which ciphers I configure (I've already asked about
> this on the dovecot list)
>
> -  postfix receives email, but:
>       - also gets lots of "454 4.7.0 TLS not available due to local
> problem" connecting to google servers
>
>       -  if I try to send email, I get this:
>
>    Our system has detected that this message does
>    550-5.7.1 not meet IPv6 sending guidelines regarding PTR
>   records and  550-5.7.1 authentication. Please review...
>
> As far as I can tell, this is a combination of postfix/dovecot
> settings not valid anymore + wrong file/folder permissions + maybe not
> compatible selinux (now set to "permissive"). I am already reading all
> the online resources I can find, but I find no clear consensus on what
> should be done. Any help is appreciated!
>
> Thanks, and here is the postfix configuration:
>
> I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:
>
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> debug_peer_level = 2
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> disable_vrfy_command = yes
> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
> inet_interfaces = all
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> mydestination = $myhostname, localhost
> mydomain = $myhostname
> myhostname = a.mx.MYDOMAIN
> mynetworks = 127.0.0.0/8, 212.110.184.219
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> non_smtpd_milters = inet:localhost:8891
> procmail_destination_recipient_limit = 1
> queue_directory = /var/spool/postfix
> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
> relay_domains =
> sample_directory = /etc/postfix
> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_sasl_auth_enable = yes
> smtp_sasl_mechanism_filter =
> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_tls_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_sender_dependent_authentication = yes
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
> smtpd_milters = inet:localhost:8891
> smtpd_recipient_restrictions = reject_invalid_hostname,
> reject_non_fqdn_hostname, reject_non_fqdn_sender,
> reject_non_fqdn_recipient, reject_unknown_sender_domain,
> reject_unknown_recipient_domain, permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination,
> check_helo_access hash:/etc/postfix/reject_own_helo,
> check_policy_service unix:postgrey/socket
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = /var/spool/postfix/private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_security_level = may
> strict_rfc821_envelopes = yes
> unknown_address_reject_code = 554
> unknown_client_reject_code = 554
> unknown_hostname_reject_code = 554
> unknown_local_recipient_reject_code = 550
> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /var/mail/mymail_storage
> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
> virtual_transport = procmail
> virtual_uid_maps = static:5000
> postconf: warning: /etc/postfix/main.cf: unused parameter:
> smtp_tls_auth_only=yes
> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D
>
>
> WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
> that they were going out of business on Dec 8th. For several personal
> reasons not relevant here (short version:  have simply been almost
> unable to work in the same weeks) I only discovered this... on Dec.
> 8th.
> I had no time at all to test anything. Saturday I bought a new VPS
> from another provider, changed DNS records to point there, set up a
> new SSL certificate with letsencrypt,  copied all the files and
> mailboxes to the new VPS and only after that I was able to start
> checking if configuration needed changes
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
When trouble shooting on systems with SELinux I put it in permissive mode -

setenforce 0

Personally I prefer to disable it, it gets in the way too often and so
far has never prevented an actual attack on any of my systems, and just
when I start to figure things out - they change how it works on me. So I
spend hours fiddling with it without benefit. But maybe I'm just not
smart enough to figure SELinux out requiring me to constantly search how
to resolve problems.

Anyway when I have to use it and there's something I need to
troubleshoot, setenforce 0 puts it in permissive mode until I solve the
problem. Just remember to setenforce 1 when it is all figured out.

For cert permissions, I use ownership of root:root with 644 on the cert
and root:root with 400 on the private key. And I keep them in
/etc/pki/tls structure with /etc/pki/tls/private being a directory only
root can read (and the private key is in that directory)

Postfix and Dovecot in CentOS systems work fine with that even though
the daemon runs as user postfix group postfix.

On 12/10/18 2:45 AM, Marco Fioretti wrote:

> Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
> <[hidden email]> ha scritto:
>
>>
>> Google is refusing access because your ipv6 PTR does not map to your domain.
>> It’s the common (now) google reverse lookup failing.
>> ...
>
> thanks for the reminder.
>
> I know, but had temporarily forgotten due to how that this migration
> "crashed" on me
> without notice, the need to have that mapping. I have already
> contacted the provider
> of the new VPS to handle this.
>
> My doubts, and consequent need for help, about my postfix configuration remain,
> however. I do *believe* that I have done everything correctly wrt generating and
> installing letsencryptcertificates.
>
> However, I know for a fact that TLS/SSL is not working in dovecot, am not
> sure at all if the postfix TLS/SSL configuration is correct, or
> complete, and I also am not sure if the interwork between dovecot and
> postfix is configured correctly.
>
> I have found several pages with contrasting advice on how to set file ownership/
> permissions for the certificate files so postfix can access them, and if / how
> selinux may have a part in theproblem (even if in my vps is set to "permissive"
> right now).  So any further comment/check on my postconf -n output is still
> very welcome (as I said, right now I am running postfix 2.10.1, while
> the config files I am using are from a
> 2.5/2.6 installation, I do not remember exactly)
>
> Thanks,
> Marco
>
>
>
>
>
>> On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:
>>
>> Greetings,
>>
>> I had my personal postfix/dovecot server, configured for some of my
>> own domains, running without problems on a linux VPS. For reasons
>> totally out of my control, I had to migrate everything to another VPS
>> two days ago, without notice, (details at the bottom if anybody is
>> interested...), and consequently without any possibility to do the due
>> homework and testing *BEFORE* the migration, so please be patient...
>>
>> The problem: since software and operating system versions are not the
>> same as before, certain settings stopped working. So far the only
>> major one I can't handle myself, both in dovecot and postfix, seems to
>> be TLS/SSL configuration. I regenerated and installed a new SSL
>> certificate with letsencrypt, but:
>>
>> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared
>> cipher", no matter which ciphers I configure (I've already asked about
>> this on the dovecot list)
>>
>> -  postfix receives email, but:
>>        - also gets lots of "454 4.7.0 TLS not available due to local
>> problem" connecting to google servers
>>
>>        -  if I try to send email, I get this:
>>
>>     Our system has detected that this message does
>>     550-5.7.1 not meet IPv6 sending guidelines regarding PTR
>>    records and  550-5.7.1 authentication. Please review...
>>
>> As far as I can tell, this is a combination of postfix/dovecot
>> settings not valid anymore + wrong file/folder permissions + maybe not
>> compatible selinux (now set to "permissive"). I am already reading all
>> the online resources I can find, but I find no clear consensus on what
>> should be done. Any help is appreciated!
>>
>> Thanks, and here is the postfix configuration:
>>
>> I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:
>>
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases
>> command_directory = /usr/sbin
>> config_directory = /etc/postfix
>> daemon_directory = /usr/libexec/postfix
>> debug_peer_level = 2
>> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
>> xxgdb $daemon_directory/$process_name $process_id & sleep 5
>> disable_vrfy_command = yes
>> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
>> inet_interfaces = all
>> mail_owner = postfix
>> mailq_path = /usr/bin/mailq.postfix
>> manpage_directory = /usr/share/man
>> mydestination = $myhostname, localhost
>> mydomain = $myhostname
>> myhostname = a.mx.MYDOMAIN
>> mynetworks = 127.0.0.0/8, 212.110.184.219
>> myorigin = $mydomain
>> newaliases_path = /usr/bin/newaliases.postfix
>> non_smtpd_milters = inet:localhost:8891
>> procmail_destination_recipient_limit = 1
>> queue_directory = /var/spool/postfix
>> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
>> relay_domains =
>> sample_directory = /etc/postfix
>> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
>> sendmail_path = /usr/sbin/sendmail.postfix
>> setgid_group = postdrop
>> smtp_sasl_auth_enable = yes
>> smtp_sasl_mechanism_filter =
>> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
>> smtp_sasl_security_options = noanonymous
>> smtp_sasl_tls_security_options = noanonymous
>> smtp_sasl_type = cyrus
>> smtp_sender_dependent_authentication = yes
>> smtp_tls_security_level = may
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions =
>> smtpd_milters = inet:localhost:8891
>> smtpd_recipient_restrictions = reject_invalid_hostname,
>> reject_non_fqdn_hostname, reject_non_fqdn_sender,
>> reject_non_fqdn_recipient, reject_unknown_sender_domain,
>> reject_unknown_recipient_domain, permit_mynetworks,
>> permit_sasl_authenticated, reject_unauth_destination,
>> check_helo_access hash:/etc/postfix/reject_own_helo,
>> check_policy_service unix:postgrey/socket
>> smtpd_sasl_auth_enable = yes
>> smtpd_sasl_path = /var/spool/postfix/private/auth
>> smtpd_sasl_type = dovecot
>> smtpd_tls_auth_only = yes
>> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
>> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
>> smtpd_tls_loglevel = 1
>> smtpd_tls_security_level = may
>> strict_rfc821_envelopes = yes
>> unknown_address_reject_code = 554
>> unknown_client_reject_code = 554
>> unknown_hostname_reject_code = 554
>> unknown_local_recipient_reject_code = 550
>> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
>> virtual_gid_maps = static:5000
>> virtual_mailbox_base = /var/mail/mymail_storage
>> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
>> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
>> virtual_transport = procmail
>> virtual_uid_maps = static:5000
>> postconf: warning: /etc/postfix/main.cf: unused parameter:
>> smtp_tls_auth_only=yes
>> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D
>>
>>
>> WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
>> that they were going out of business on Dec 8th. For several personal
>> reasons not relevant here (short version:  have simply been almost
>> unable to work in the same weeks) I only discovered this... on Dec.
>> 8th.
>> I had no time at all to test anything. Saturday I bought a new VPS
>> from another provider, changed DNS records to point there, set up a
>> new SSL certificate with letsencrypt,  copied all the files and
>> mailboxes to the new VPS and only after that I was able to start
>> checking if configuration needed changes

--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

rachalmers


Just looking at this again…

Do you have in or remember to update…. (note the use of <your domain> as a marker)

dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/letsencrypt/live/<your domain>/fullchain.pem
ssl_key = </etc/letsencrypt/live/<your domain>/privkey.pem



and in postfix/main.cf

#TLS parameters
smtpd_use_tls=yes
smtpd_tls_ciphers = medium
smtpd_tls_security_level = may
smtpd_tls_key_file = /etc/letsencrypt/live/<your domain>/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/<your domain>/fullchain.pem
smtpd_tls_CAfile = /private/etc/ssl/certs/gd_bundle-g2-g1.crt
# List of ciphers or cipher types to exclude from the SMTP server cipher
# list at all TLS security levels.
smtpd_tls_exclude_ciphers = SSLv2, aNULL, ADH, eNULL
smtpd_tls_ciphers = medium
smtpd_tls_security_level = may



and this seems to be useful for testing your certs…

openssl s_client -showcerts -servername <your domain> -connect <your domain>:443   or 586 I think it is.



and don’t forget to rebuild your aliases and postmap your db files if you have them.

As a side not, I managed to buildpostfix-3.4-20181125 and am now running that. the configs remain much the same though.

hope tht may help

Robert



> On 10 Dec 2018, at 11:08, Alice Wonder <[hidden email]> wrote:
>
> When trouble shooting on systems with SELinux I put it in permissive mode -
>
> setenforce 0
>
> Personally I prefer to disable it, it gets in the way too often and so far has never prevented an actual attack on any of my systems, and just when I start to figure things out - they change how it works on me. So I spend hours fiddling with it without benefit. But maybe I'm just not smart enough to figure SELinux out requiring me to constantly search how to resolve problems.
>
> Anyway when I have to use it and there's something I need to troubleshoot, setenforce 0 puts it in permissive mode until I solve the problem. Just remember to setenforce 1 when it is all figured out.
>
> For cert permissions, I use ownership of root:root with 644 on the cert and root:root with 400 on the private key. And I keep them in /etc/pki/tls structure with /etc/pki/tls/private being a directory only root can read (and the private key is in that directory)
>
> Postfix and Dovecot in CentOS systems work fine with that even though the daemon runs as user postfix group postfix.
>
> On 12/10/18 2:45 AM, Marco Fioretti wrote:
>> Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
>> <[hidden email]> ha scritto:
>>>
>>> Google is refusing access because your ipv6 PTR does not map to your domain.
>>> It’s the common (now) google reverse lookup failing.
>>> ...
>> thanks for the reminder.
>> I know, but had temporarily forgotten due to how that this migration
>> "crashed" on me
>> without notice, the need to have that mapping. I have already
>> contacted the provider
>> of the new VPS to handle this.
>> My doubts, and consequent need for help, about my postfix configuration remain,
>> however. I do *believe* that I have done everything correctly wrt generating and
>> installing letsencryptcertificates.
>> However, I know for a fact that TLS/SSL is not working in dovecot, am not
>> sure at all if the postfix TLS/SSL configuration is correct, or
>> complete, and I also am not sure if the interwork between dovecot and
>> postfix is configured correctly.
>> I have found several pages with contrasting advice on how to set file ownership/
>> permissions for the certificate files so postfix can access them, and if / how
>> selinux may have a part in theproblem (even if in my vps is set to "permissive"
>> right now).  So any further comment/check on my postconf -n output is still
>> very welcome (as I said, right now I am running postfix 2.10.1, while
>> the config files I am using are from a
>> 2.5/2.6 installation, I do not remember exactly)
>> Thanks,
>> Marco
>>> On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:
>>>
>>> Greetings,
>>>
>>> I had my personal postfix/dovecot server, configured for some of my
>>> own domains, running without problems on a linux VPS. For reasons
>>> totally out of my control, I had to migrate everything to another VPS
>>> two days ago, without notice, (details at the bottom if anybody is
>>> interested...), and consequently without any possibility to do the due
>>> homework and testing *BEFORE* the migration, so please be patient...
>>>
>>> The problem: since software and operating system versions are not the
>>> same as before, certain settings stopped working. So far the only
>>> major one I can't handle myself, both in dovecot and postfix, seems to
>>> be TLS/SSL configuration. I regenerated and installed a new SSL
>>> certificate with letsencrypt, but:
>>>
>>> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared
>>> cipher", no matter which ciphers I configure (I've already asked about
>>> this on the dovecot list)
>>>
>>> -  postfix receives email, but:
>>>       - also gets lots of "454 4.7.0 TLS not available due to local
>>> problem" connecting to google servers
>>>
>>>       -  if I try to send email, I get this:
>>>
>>>    Our system has detected that this message does
>>>    550-5.7.1 not meet IPv6 sending guidelines regarding PTR
>>>   records and  550-5.7.1 authentication. Please review...
>>>
>>> As far as I can tell, this is a combination of postfix/dovecot
>>> settings not valid anymore + wrong file/folder permissions + maybe not
>>> compatible selinux (now set to "permissive"). I am already reading all
>>> the online resources I can find, but I find no clear consensus on what
>>> should be done. Any help is appreciated!
>>>
>>> Thanks, and here is the postfix configuration:
>>>
>>> I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:
>>>
>>> alias_database = hash:/etc/aliases
>>> alias_maps = hash:/etc/aliases
>>> command_directory = /usr/sbin
>>> config_directory = /etc/postfix
>>> daemon_directory = /usr/libexec/postfix
>>> debug_peer_level = 2
>>> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
>>> xxgdb $daemon_directory/$process_name $process_id & sleep 5
>>> disable_vrfy_command = yes
>>> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
>>> inet_interfaces = all
>>> mail_owner = postfix
>>> mailq_path = /usr/bin/mailq.postfix
>>> manpage_directory = /usr/share/man
>>> mydestination = $myhostname, localhost
>>> mydomain = $myhostname
>>> myhostname = a.mx.MYDOMAIN
>>> mynetworks = 127.0.0.0/8, 212.110.184.219
>>> myorigin = $mydomain
>>> newaliases_path = /usr/bin/newaliases.postfix
>>> non_smtpd_milters = inet:localhost:8891
>>> procmail_destination_recipient_limit = 1
>>> queue_directory = /var/spool/postfix
>>> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
>>> relay_domains =
>>> sample_directory = /etc/postfix
>>> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
>>> sendmail_path = /usr/sbin/sendmail.postfix
>>> setgid_group = postdrop
>>> smtp_sasl_auth_enable = yes
>>> smtp_sasl_mechanism_filter =
>>> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
>>> smtp_sasl_security_options = noanonymous
>>> smtp_sasl_tls_security_options = noanonymous
>>> smtp_sasl_type = cyrus
>>> smtp_sender_dependent_authentication = yes
>>> smtp_tls_security_level = may
>>> smtpd_helo_required = yes
>>> smtpd_helo_restrictions =
>>> smtpd_milters = inet:localhost:8891
>>> smtpd_recipient_restrictions = reject_invalid_hostname,
>>> reject_non_fqdn_hostname, reject_non_fqdn_sender,
>>> reject_non_fqdn_recipient, reject_unknown_sender_domain,
>>> reject_unknown_recipient_domain, permit_mynetworks,
>>> permit_sasl_authenticated, reject_unauth_destination,
>>> check_helo_access hash:/etc/postfix/reject_own_helo,
>>> check_policy_service unix:postgrey/socket
>>> smtpd_sasl_auth_enable = yes
>>> smtpd_sasl_path = /var/spool/postfix/private/auth
>>> smtpd_sasl_type = dovecot
>>> smtpd_tls_auth_only = yes
>>> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
>>> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
>>> smtpd_tls_loglevel = 1
>>> smtpd_tls_security_level = may
>>> strict_rfc821_envelopes = yes
>>> unknown_address_reject_code = 554
>>> unknown_client_reject_code = 554
>>> unknown_hostname_reject_code = 554
>>> unknown_local_recipient_reject_code = 550
>>> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
>>> virtual_gid_maps = static:5000
>>> virtual_mailbox_base = /var/mail/mymail_storage
>>> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
>>> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
>>> virtual_transport = procmail
>>> virtual_uid_maps = static:5000
>>> postconf: warning: /etc/postfix/main.cf: unused parameter:
>>> smtp_tls_auth_only=yes
>>> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D
>>>
>>>
>>> WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
>>> that they were going out of business on Dec 8th. For several personal
>>> reasons not relevant here (short version:  have simply been almost
>>> unable to work in the same weeks) I only discovered this... on Dec.
>>> 8th.
>>> I had no time at all to test anything. Saturday I bought a new VPS
>>> from another provider, changed DNS records to point there, set up a
>>> new SSL certificate with letsencrypt,  copied all the files and
>>> mailboxes to the new VPS and only after that I was able to start
>>> checking if configuration needed changes
>
>
> --
> For signature trust anchor (paranoid only need worry 'bout this):
> https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt
>
> Webmail clients, sorry, out of luck, you can't import it.
> Get an actual e-mail app.
>

Robert Chalmers
https://robert-chalmers.uk
[hidden email]
@R_A_Chalmers

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Marco Fioretti
In reply to this post by Alice Wonder
Hello Alice, see answers in line


Il giorno lun 10 dic 2018 alle ore 12:09 Alice Wonder
<[hidden email]> ha scritto:
>
> When trouble shooting on systems with SELinux I put it in permissive mode -
> setenforce 0

this is already the case on the new VPS (FWIW, I personally share your
feelingsabout selinux in general, but that is another story..)

> For cert permissions, I use ownership of root:root with 644 on the cert
> and root:root with 400 on the private key. And I keep them in
> /etc/pki/tls structure with /etc/pki/tls/private being a directory only
> root can read (and the private key is in that directory)

I just changed my permission in the same way, except that the files
are in another folder (does it make any difference? It shouldn't
right?), i.e.
the same where letsencrypt/certbot put them:

-r--------. 1 root root     3546 Dec  7 11:59 fullchain1.pem
-rw-r--r--. 1 root root     1704 Dec  7 11:59 privkey1.pem

and FWIW, as far as dovecot is concerned, this did not change things a
bit, , I still can't get the "no shared cipher" abort message, even if
dovecot/postfix config should point to/have the same config for these
keys, right? This part is really confusing.

Not sure if I can test anything more on the postfix side, until the
reverse pointer gets updated in DNS. Or not?

Thanks,
Marco

>
> Postfix and Dovecot in CentOS systems work fine with that even though
> the daemon runs as user postfix group postfix.
>
> On 12/10/18 2:45 AM, Marco Fioretti wrote:
> > Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
> > <[hidden email]> ha scritto:
> >
> >>
> >> Google is refusing access because your ipv6 PTR does not map to your domain.
> >> It’s the common (now) google reverse lookup failing.
> >> ...
> >
> > thanks for the reminder.
> >
> > I know, but had temporarily forgotten due to how that this migration
> > "crashed" on me
> > without notice, the need to have that mapping. I have already
> > contacted the provider
> > of the new VPS to handle this.
> >
> > My doubts, and consequent need for help, about my postfix configuration remain,
> > however. I do *believe* that I have done everything correctly wrt generating and
> > installing letsencryptcertificates.
> >
> > However, I know for a fact that TLS/SSL is not working in dovecot, am not
> > sure at all if the postfix TLS/SSL configuration is correct, or
> > complete, and I also am not sure if the interwork between dovecot and
> > postfix is configured correctly.
> >
> > I have found several pages with contrasting advice on how to set file ownership/
> > permissions for the certificate files so postfix can access them, and if / how
> > selinux may have a part in theproblem (even if in my vps is set to "permissive"
> > right now).  So any further comment/check on my postconf -n output is still
> > very welcome (as I said, right now I am running postfix 2.10.1, while
> > the config files I am using are from a
> > 2.5/2.6 installation, I do not remember exactly)
> >
> > Thanks,
> > Marco
> >
> >
> >
> >
> >
> >> On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:
> >>
> >> Greetings,
> >>
> >> I had my personal postfix/dovecot server, configured for some of my
> >> own domains, running without problems on a linux VPS. For reasons
> >> totally out of my control, I had to migrate everything to another VPS
> >> two days ago, without notice, (details at the bottom if anybody is
> >> interested...), and consequently without any possibility to do the due
> >> homework and testing *BEFORE* the migration, so please be patient...
> >>
> >> The problem: since software and operating system versions are not the
> >> same as before, certain settings stopped working. So far the only
> >> major one I can't handle myself, both in dovecot and postfix, seems to
> >> be TLS/SSL configuration. I regenerated and installed a new SSL
> >> certificate with letsencrypt, but:
> >>
> >> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared
> >> cipher", no matter which ciphers I configure (I've already asked about
> >> this on the dovecot list)
> >>
> >> -  postfix receives email, but:
> >>        - also gets lots of "454 4.7.0 TLS not available due to local
> >> problem" connecting to google servers
> >>
> >>        -  if I try to send email, I get this:
> >>
> >>     Our system has detected that this message does
> >>     550-5.7.1 not meet IPv6 sending guidelines regarding PTR
> >>    records and  550-5.7.1 authentication. Please review...
> >>
> >> As far as I can tell, this is a combination of postfix/dovecot
> >> settings not valid anymore + wrong file/folder permissions + maybe not
> >> compatible selinux (now set to "permissive"). I am already reading all
> >> the online resources I can find, but I find no clear consensus on what
> >> should be done. Any help is appreciated!
> >>
> >> Thanks, and here is the postfix configuration:
> >>
> >> I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:
> >>
> >> alias_database = hash:/etc/aliases
> >> alias_maps = hash:/etc/aliases
> >> command_directory = /usr/sbin
> >> config_directory = /etc/postfix
> >> daemon_directory = /usr/libexec/postfix
> >> debug_peer_level = 2
> >> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> >> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> >> disable_vrfy_command = yes
> >> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
> >> inet_interfaces = all
> >> mail_owner = postfix
> >> mailq_path = /usr/bin/mailq.postfix
> >> manpage_directory = /usr/share/man
> >> mydestination = $myhostname, localhost
> >> mydomain = $myhostname
> >> myhostname = a.mx.MYDOMAIN
> >> mynetworks = 127.0.0.0/8, 212.110.184.219
> >> myorigin = $mydomain
> >> newaliases_path = /usr/bin/newaliases.postfix
> >> non_smtpd_milters = inet:localhost:8891
> >> procmail_destination_recipient_limit = 1
> >> queue_directory = /var/spool/postfix
> >> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
> >> relay_domains =
> >> sample_directory = /etc/postfix
> >> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
> >> sendmail_path = /usr/sbin/sendmail.postfix
> >> setgid_group = postdrop
> >> smtp_sasl_auth_enable = yes
> >> smtp_sasl_mechanism_filter =
> >> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
> >> smtp_sasl_security_options = noanonymous
> >> smtp_sasl_tls_security_options = noanonymous
> >> smtp_sasl_type = cyrus
> >> smtp_sender_dependent_authentication = yes
> >> smtp_tls_security_level = may
> >> smtpd_helo_required = yes
> >> smtpd_helo_restrictions =
> >> smtpd_milters = inet:localhost:8891
> >> smtpd_recipient_restrictions = reject_invalid_hostname,
> >> reject_non_fqdn_hostname, reject_non_fqdn_sender,
> >> reject_non_fqdn_recipient, reject_unknown_sender_domain,
> >> reject_unknown_recipient_domain, permit_mynetworks,
> >> permit_sasl_authenticated, reject_unauth_destination,
> >> check_helo_access hash:/etc/postfix/reject_own_helo,
> >> check_policy_service unix:postgrey/socket
> >> smtpd_sasl_auth_enable = yes
> >> smtpd_sasl_path = /var/spool/postfix/private/auth
> >> smtpd_sasl_type = dovecot
> >> smtpd_tls_auth_only = yes
> >> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
> >> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
> >> smtpd_tls_loglevel = 1
> >> smtpd_tls_security_level = may
> >> strict_rfc821_envelopes = yes
> >> unknown_address_reject_code = 554
> >> unknown_client_reject_code = 554
> >> unknown_hostname_reject_code = 554
> >> unknown_local_recipient_reject_code = 550
> >> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
> >> virtual_gid_maps = static:5000
> >> virtual_mailbox_base = /var/mail/mymail_storage
> >> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
> >> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
> >> virtual_transport = procmail
> >> virtual_uid_maps = static:5000
> >> postconf: warning: /etc/postfix/main.cf: unused parameter:
> >> smtp_tls_auth_only=yes
> >> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D
> >>
> >>
> >> WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
> >> that they were going out of business on Dec 8th. For several personal
> >> reasons not relevant here (short version:  have simply been almost
> >> unable to work in the same weeks) I only discovered this... on Dec.
> >> 8th.
> >> I had no time at all to test anything. Saturday I bought a new VPS
> >> from another provider, changed DNS records to point there, set up a
> >> new SSL certificate with letsencrypt,  copied all the files and
> >> mailboxes to the new VPS and only after that I was able to start
> >> checking if configuration needed changes
>
>
> --
> For signature trust anchor (paranoid only need worry 'bout this):
> https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt
>
> Webmail clients, sorry, out of luck, you can't import it.
> Get an actual e-mail app.
>
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
Sorry about the setenforce advice, I didn't see you already had that
covered.

The path for the certs should not matter as long as the files exist.

One thing with dovecot - make sure the PEM file has the cert and the
bundle in it.

cat certificate.pem ca-bundle.pem > combined.pem

Then set

ssl_cert = </path/to/combined.pem

(names don't matter) - not sure that is your problem though.

The description "no shared cipher" - if I remember, I think that means
the client and the server do not have any ciphers in common they both use.

This is what I use in dovecot:

ssl_min_protocol = TLSv1.2
ssl_cipher_list =
EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
ssl_prefer_server_ciphers = yes

That is small list but works with all the IMAP clients I have to support
(and I think the !cipher that I have are not actually needed)



On 12/10/18 4:02 AM, Marco Fioretti wrote:

> Hello Alice, see answers in line
>
>
> Il giorno lun 10 dic 2018 alle ore 12:09 Alice Wonder
> <[hidden email]> ha scritto:
>>
>> When trouble shooting on systems with SELinux I put it in permissive mode -
>> setenforce 0
>
> this is already the case on the new VPS (FWIW, I personally share your
> feelingsabout selinux in general, but that is another story..)
>
>> For cert permissions, I use ownership of root:root with 644 on the cert
>> and root:root with 400 on the private key. And I keep them in
>> /etc/pki/tls structure with /etc/pki/tls/private being a directory only
>> root can read (and the private key is in that directory)
>
> I just changed my permission in the same way, except that the files
> are in another folder (does it make any difference? It shouldn't
> right?), i.e.
> the same where letsencrypt/certbot put them:
>
> -r--------. 1 root root     3546 Dec  7 11:59 fullchain1.pem
> -rw-r--r--. 1 root root     1704 Dec  7 11:59 privkey1.pem
>
> and FWIW, as far as dovecot is concerned, this did not change things a
> bit, , I still can't get the "no shared cipher" abort message, even if
> dovecot/postfix config should point to/have the same config for these
> keys, right? This part is really confusing.
>
> Not sure if I can test anything more on the postfix side, until the
> reverse pointer gets updated in DNS. Or not?
>
> Thanks,
> Marco
>
>>
>> Postfix and Dovecot in CentOS systems work fine with that even though
>> the daemon runs as user postfix group postfix.
>>
>> On 12/10/18 2:45 AM, Marco Fioretti wrote:
>>> Il giorno lun 10 dic 2018 alle ore 09:14 Robert Chalmers
>>> <[hidden email]> ha scritto:
>>>
>>>>
>>>> Google is refusing access because your ipv6 PTR does not map to your domain.
>>>> It’s the common (now) google reverse lookup failing.
>>>> ...
>>>
>>> thanks for the reminder.
>>>
>>> I know, but had temporarily forgotten due to how that this migration
>>> "crashed" on me
>>> without notice, the need to have that mapping. I have already
>>> contacted the provider
>>> of the new VPS to handle this.
>>>
>>> My doubts, and consequent need for help, about my postfix configuration remain,
>>> however. I do *believe* that I have done everything correctly wrt generating and
>>> installing letsencryptcertificates.
>>>
>>> However, I know for a fact that TLS/SSL is not working in dovecot, am not
>>> sure at all if the postfix TLS/SSL configuration is correct, or
>>> complete, and I also am not sure if the interwork between dovecot and
>>> postfix is configured correctly.
>>>
>>> I have found several pages with contrasting advice on how to set file ownership/
>>> permissions for the certificate files so postfix can access them, and if / how
>>> selinux may have a part in theproblem (even if in my vps is set to "permissive"
>>> right now).  So any further comment/check on my postconf -n output is still
>>> very welcome (as I said, right now I am running postfix 2.10.1, while
>>> the config files I am using are from a
>>> 2.5/2.6 installation, I do not remember exactly)
>>>
>>> Thanks,
>>> Marco
>>>
>>>
>>>
>>>
>>>
>>>> On 10 Dec 2018, at 8:08 am, Marco Fioretti <[hidden email]> wrote:
>>>>
>>>> Greetings,
>>>>
>>>> I had my personal postfix/dovecot server, configured for some of my
>>>> own domains, running without problems on a linux VPS. For reasons
>>>> totally out of my control, I had to migrate everything to another VPS
>>>> two days ago, without notice, (details at the bottom if anybody is
>>>> interested...), and consequently without any possibility to do the due
>>>> homework and testing *BEFORE* the migration, so please be patient...
>>>>
>>>> The problem: since software and operating system versions are not the
>>>> same as before, certain settings stopped working. So far the only
>>>> major one I can't handle myself, both in dovecot and postfix, seems to
>>>> be TLS/SSL configuration. I regenerated and installed a new SSL
>>>> certificate with letsencrypt, but:
>>>>
>>>> - in dovecot, I can't connect because "ssl3_get_client_hello:no shared
>>>> cipher", no matter which ciphers I configure (I've already asked about
>>>> this on the dovecot list)
>>>>
>>>> -  postfix receives email, but:
>>>>         - also gets lots of "454 4.7.0 TLS not available due to local
>>>> problem" connecting to google servers
>>>>
>>>>         -  if I try to send email, I get this:
>>>>
>>>>      Our system has detected that this message does
>>>>      550-5.7.1 not meet IPv6 sending guidelines regarding PTR
>>>>     records and  550-5.7.1 authentication. Please review...
>>>>
>>>> As far as I can tell, this is a combination of postfix/dovecot
>>>> settings not valid anymore + wrong file/folder permissions + maybe not
>>>> compatible selinux (now set to "permissive"). I am already reading all
>>>> the online resources I can find, but I find no clear consensus on what
>>>> should be done. Any help is appreciated!
>>>>
>>>> Thanks, and here is the postfix configuration:
>>>>
>>>> I am running postfix 2.10.1 on Centos 7.6. Here is the output of postconf -n:
>>>>
>>>> alias_database = hash:/etc/aliases
>>>> alias_maps = hash:/etc/aliases
>>>> command_directory = /usr/sbin
>>>> config_directory = /etc/postfix
>>>> daemon_directory = /usr/libexec/postfix
>>>> debug_peer_level = 2
>>>> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
>>>> xxgdb $daemon_directory/$process_name $process_id & sleep 5
>>>> disable_vrfy_command = yes
>>>> html_directory = /usr/share/doc/postfix-2.4.3-documentation/html
>>>> inet_interfaces = all
>>>> mail_owner = postfix
>>>> mailq_path = /usr/bin/mailq.postfix
>>>> manpage_directory = /usr/share/man
>>>> mydestination = $myhostname, localhost
>>>> mydomain = $myhostname
>>>> myhostname = a.mx.MYDOMAIN
>>>> mynetworks = 127.0.0.0/8, 212.110.184.219
>>>> myorigin = $mydomain
>>>> newaliases_path = /usr/bin/newaliases.postfix
>>>> non_smtpd_milters = inet:localhost:8891
>>>> procmail_destination_recipient_limit = 1
>>>> queue_directory = /var/spool/postfix
>>>> readme_directory = /usr/share/doc/postfix-2.4.3-documentation/readme
>>>> relay_domains =
>>>> sample_directory = /etc/postfix
>>>> sender_dependent_relayhost_maps = hash:/etc/postfix/mymaps/relayhost_maps
>>>> sendmail_path = /usr/sbin/sendmail.postfix
>>>> setgid_group = postdrop
>>>> smtp_sasl_auth_enable = yes
>>>> smtp_sasl_mechanism_filter =
>>>> smtp_sasl_password_maps = hash:/etc/postfix/mymaps/sasl_passwd
>>>> smtp_sasl_security_options = noanonymous
>>>> smtp_sasl_tls_security_options = noanonymous
>>>> smtp_sasl_type = cyrus
>>>> smtp_sender_dependent_authentication = yes
>>>> smtp_tls_security_level = may
>>>> smtpd_helo_required = yes
>>>> smtpd_helo_restrictions =
>>>> smtpd_milters = inet:localhost:8891
>>>> smtpd_recipient_restrictions = reject_invalid_hostname,
>>>> reject_non_fqdn_hostname, reject_non_fqdn_sender,
>>>> reject_non_fqdn_recipient, reject_unknown_sender_domain,
>>>> reject_unknown_recipient_domain, permit_mynetworks,
>>>> permit_sasl_authenticated, reject_unauth_destination,
>>>> check_helo_access hash:/etc/postfix/reject_own_helo,
>>>> check_policy_service unix:postgrey/socket
>>>> smtpd_sasl_auth_enable = yes
>>>> smtpd_sasl_path = /var/spool/postfix/private/auth
>>>> smtpd_sasl_type = dovecot
>>>> smtpd_tls_auth_only = yes
>>>> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
>>>> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem
>>>> smtpd_tls_loglevel = 1
>>>> smtpd_tls_security_level = may
>>>> strict_rfc821_envelopes = yes
>>>> unknown_address_reject_code = 554
>>>> unknown_client_reject_code = 554
>>>> unknown_hostname_reject_code = 554
>>>> unknown_local_recipient_reject_code = 550
>>>> virtual_alias_maps = hash:/etc/postfix/mymaps/valias.map
>>>> virtual_gid_maps = static:5000
>>>> virtual_mailbox_base = /var/mail/mymail_storage
>>>> virtual_mailbox_domains = /etc/postfix/mymaps/vhosts.map
>>>> virtual_mailbox_maps = hash:/etc/postfix/mymaps/vmailboxes.map
>>>> virtual_transport = procmail
>>>> virtual_uid_maps = static:5000
>>>> postconf: warning: /etc/postfix/main.cf: unused parameter:
>>>> smtp_tls_auth_only=yes
>>>> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D
>>>>
>>>>
>>>> WHY THIS HAPPENED: A few weeks ago, the old VPS provider communicated
>>>> that they were going out of business on Dec 8th. For several personal
>>>> reasons not relevant here (short version:  have simply been almost
>>>> unable to work in the same weeks) I only discovered this... on Dec.
>>>> 8th.
>>>> I had no time at all to test anything. Saturday I bought a new VPS
>>>> from another provider, changed DNS records to point there, set up a
>>>> new SSL certificate with letsencrypt,  copied all the files and
>>>> mailboxes to the new VPS and only after that I was able to start
>>>> checking if configuration needed changes
>>
>>
>> --
>> For signature trust anchor (paranoid only need worry 'bout this):
>> https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt
>>
>> Webmail clients, sorry, out of luck, you can't import it.
>> Get an actual e-mail app.
>>

--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Viktor Dukhovni
In reply to this post by Marco Fioretti
On Mon, Dec 10, 2018 at 01:02:25PM +0100, Marco Fioretti wrote:

> I just changed my permission in the same way, except that the files
> are in another folder (does it make any difference? It shouldn't
> right?), i.e.  the same where letsencrypt/certbot put them:
>
> -r--------. 1 root root     3546 Dec  7 11:59 fullchain1.pem
> -rw-r--r--. 1 root root     1704 Dec  7 11:59 privkey1.pem

This looks rather odd.  You're keeping your public certificate chain
protected, but making the keys world-readable???

On Mon, Dec 10, 2018 at 09:08:09AM +0100, Marco Fioretti wrote:

> smtpd_tls_cert_file = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem
> smtpd_tls_key_file = /etc/letsencrypt/live/MYDOMAIN/privkey.pem

Furthermore, you list "fullchain1.pem", but the configuration
has "fullchain.pem" (which is more typical).  So which is it?

> smtpd_tls_loglevel = 1

And you've not posted the log messages with the warnings wherein
Postfix logs the actual problem enabling TLS.

> postconf: warning: /etc/postfix/main.cf: unused parameter:
> smtp_tls_auth_only=yes
> postconf: warning: /etc/postfix/master.cf: unused parameter: flags=D

And in master.cf you override "smtp_tls_auth_only", but there's no
such parameter, perhaps you meant "smtp_sasl_tls_auth_only"?  And
"flags=D" is in the wrong context on some line.  Check the pipe(8)
manpage and e.g. the examples in:

    http://www.postfix.org/MAILDROP_README.html

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Marco Fioretti
Hello Viktor, and all.

This is only a partial answer to Viktor last email:

Il giorno lun 10 dic 2018 alle ore 13:56 Viktor Dukhovni
<[hidden email]> ha scritto:

> > -r--------. 1 root root     3546 Dec  7 11:59 fullchain1.pem
> > -rw-r--r--. 1 root root     1704 Dec  7 11:59 privkey1.pem
>
> This looks rather odd.  You're keeping your public certificate chain
> protected, but making the keys world-readable???

the setting of privkey to 644 comes from one of Alice's answers (I may
have misinterpreted it, of course, but that is where it comes from).

About all the other suggestions:

This afternoon I have urgent family matters to attend, not sure if I
will able to test and report before tomorrow afternoon about all the
other advice I got so far. Any further comment or tip that comes in
the meantime is welcome,of course. Tonight or tomorrow I will print
out all the answers, and try to re-apply them from scratch, starting
with a new, default configuration file. For now, I want to thank
everybody again for all the hand-holding I am requesting, and will
likely need for a few more days.

In normal circumstances, I would have taken and planned this migration
as a nice occasion to refresh, without hurrying, all my sisadmin
skills. As it went, the server was literally pulled off under my feet,
in a period when, theoretically, I should slow down and focus on
non-work matters. But I need to restore email anyway asap, and right
now it feels as being forced to solve a puzzle without knowing what it
represents...

Later,
Marco
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Viktor Dukhovni
> On Dec 10, 2018, at 9:46 AM, Marco Fioretti <[hidden email]> wrote:
>
> This afternoon I have urgent family matters to attend, not sure if I
> will able to test and report before tomorrow afternoon about all the
> other advice I got so far.

You can skip all the other advice.  You need to post logs, specifically
logs that report the problem initializing TLS support in smtpd(8) and
smtp(8).  You also need to confirm the configured file names, and
report "ls -l" output for the *exact* files in your configuration, not
some similarly named files.  The file permissions should be standard,
owner root mode 0600 for private keys, and either 0600 or 0644 for
certs if separate and there are no keys in the cert files.

> But I need to restore email anyway asap, and right
> now it feels as being forced to solve a puzzle without knowing what it
> represents...

The answers are in the logs.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
In reply to this post by Marco Fioretti
On 12/10/18 6:46 AM, Marco Fioretti wrote:

> Hello Viktor, and all.
>
> This is only a partial answer to Viktor last email:
>
> Il giorno lun 10 dic 2018 alle ore 13:56 Viktor Dukhovni
> <[hidden email]> ha scritto:
>
>>> -r--------. 1 root root     3546 Dec  7 11:59 fullchain1.pem
>>> -rw-r--r--. 1 root root     1704 Dec  7 11:59 privkey1.pem
>>
>> This looks rather odd.  You're keeping your public certificate chain
>> protected, but making the keys world-readable???
>
> the setting of privkey to 644 comes from one of Alice's answers (I may
> have misinterpreted it, of course, but that is where it comes from).
If I suggest 644 for private I mis-typed (happens)

644 is what I use for cert
400 is what I use for private


--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Jim P.
In reply to this post by Alice Wonder
On Mon, 2018-12-10 at 04:22 -0800, Alice Wonder wrote:
> ssl_min_protocol = TLSv1.2
> ssl_cipher_list = 
> EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4
> :!ADH:!LOW@STRENGTH
> ssl_prefer_server_ciphers = yes

Don't forget about ssl_dh_parameters_length, it's default on Debian is
1024.

-Jim P.
Reply | Threaded
Open this post in threaded view
|

RE: SSL not working after unwanted server migration

Fazzina, Angelo
In reply to this post by Viktor Dukhovni
Hi, once you correct your configuration this may help you test it is correct


1. Run this to test connectivity to your server via STARTTLS  [Submission in master.cf]
openssl s_client -starttls smtp -connect your.host.name:587
        Typical OUTPUT =
                250 DSN
                quit
                221 2.0.0 Bye
                closed
2. Run this to test connectivity to your server via SMTPS
openssl s_client  -connect your.host.name:465
        Typical OUTPUT =
                220 your.host.name ESMTP Postfix (2.10.1)

3. Run this to create a hash
python -c 'import base64,sys; u,p=sys.argv[1:3]; print base64.encodestring("%s\x00%s\x00%s" % (u,u,p))' username password
        OUTPUT = dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=
Replace username and password with real ones

Once Steps 1 and 2 work, you can test authentication with the hash in Step 3

4. Run the openssl commands and connect to your server.
        A. do and "ehlo domain" to see commands supported
                EXAMPLE :
                ehlo domain
                250-localpart.domain.part
                250-PIPELINING
                250-SIZE 31457280
                250-VRFY
                250-ETRN
                250-AUTH PLAIN LOGIN
                250-ENHANCEDSTATUSCODES
                250-8BITMIME
                250 DSN
        B. execute the AUTH PLAIN LOGIN command option using the HASH you made in Step 3
                AUTH PLAIN dXNlcm5hbWUAdXNlcm5hbWUAcGFzc3dvcmQ=

        C. look for output
                235 2.7.0 Authentication successful

5. you can just type quit or finish the smtp commands and send yourself an email. Also errors should show up at stdout if you still have any.

-ANGELO FAZZINA

ITS Service Manager:
Spam and Virus Prevention
Mass Mailing
G Suite/Gmail

[hidden email]
University of Connecticut,  ITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] <[hidden email]> On Behalf Of Viktor Dukhovni
Sent: Monday, December 10, 2018 10:01 AM
To: Postfix users <[hidden email]>
Subject: Re: SSL not working after unwanted server migration

> On Dec 10, 2018, at 9:46 AM, Marco Fioretti <[hidden email]> wrote:
>
> This afternoon I have urgent family matters to attend, not sure if I
> will able to test and report before tomorrow afternoon about all the
> other advice I got so far.

You can skip all the other advice.  You need to post logs, specifically
logs that report the problem initializing TLS support in smtpd(8) and
smtp(8).  You also need to confirm the configured file names, and
report "ls -l" output for the *exact* files in your configuration, not
some similarly named files.  The file permissions should be standard,
owner root mode 0600 for private keys, and either 0600 or 0644 for
certs if separate and there are no keys in the cert files.

> But I need to restore email anyway asap, and right
> now it feels as being forced to solve a puzzle without knowing what it
> represents...

The answers are in the logs.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Viktor Dukhovni
In reply to this post by Alice Wonder
> On Dec 10, 2018, at 7:22 AM, Alice Wonder <[hidden email]> wrote:
>
> ssl_min_protocol = TLSv1.2
> ssl_cipher_list = EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
> ssl_prefer_server_ciphers = yes

The cipherlist syntax is wrong, you're missing a ":" between "!LOW" and "@STRENGTH".
My advice is that non-experts should not be asked or attempt to configure explicit
TLS cipherlists.  Let the defaults stand, and use software that comes with sensible
defaults, upgrading periodically to keep the default configuration current.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

rachalmers
Marco
Post your logs showing the errors.







__________
Robert Chalmers
https://robert-chalmers.uk
[hidden email]
@R_A_Chalmers

On 10 Dec 2018, at 8:25 pm, Viktor Dukhovni <[hidden email]> wrote:

On Dec 10, 2018, at 7:22 AM, Alice Wonder <[hidden email]> wrote:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
ssl_prefer_server_ciphers = yes

The cipherlist syntax is wrong, you're missing a ":" between "!LOW" and "@STRENGTH".
My advice is that non-experts should not be asked or attempt to configure explicit
TLS cipherlists.  Let the defaults stand, and use software that comes with sensible
defaults, upgrading periodically to keep the default configuration current.

--
   Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Andrey Repin-2
In reply to this post by Alice Wonder
Greetings, Alice Wonder!

> This is what I use in dovecot:

> ssl_min_protocol = TLSv1.2
> ssl_cipher_list =
> EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
> ssl_prefer_server_ciphers = yes

Don't touch SSL chipherlist unless you 100% know what you are doing or there's
a security advisory from vendor suggesting a change.


--
With best regards,
Andrey Repin
Tuesday, December 11, 2018 3:44:28

Sorry for my terrible english...

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
In reply to this post by Viktor Dukhovni
On 12/10/18 12:25 PM, Viktor Dukhovni wrote:

>> On Dec 10, 2018, at 7:22 AM, Alice Wonder <[hidden email]> wrote:
>>
>> ssl_min_protocol = TLSv1.2
>> ssl_cipher_list = EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
>> ssl_prefer_server_ciphers = yes
>
> The cipherlist syntax is wrong, you're missing a ":" between "!LOW" and "@STRENGTH".
> My advice is that non-experts should not be asked or attempt to configure explicit
> TLS cipherlists.  Let the defaults stand, and use software that comes with sensible
> defaults, upgrading periodically to keep the default configuration current.
>
You are right there is a typo that didn't get caught.

You are actually wrong that it is better to let defaults stand. With a
lot of software, upstream doesn't give a damn.

Even in this thread someone pointed out that Debian defaults to 1024-bit
RSA. You end up with things like SHA1 still enabled because upstream
thought the compatibility mattered more than the security.

So yes, I made a typo, and maybe I'm not a guru but the reason why I
fiddle with this stuff is because when I didn't - too often the
"experts" left things in a way that were dangerous.

--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
On 12/10/18 5:19 PM, Alice Wonder wrote:

> On 12/10/18 12:25 PM, Viktor Dukhovni wrote:
>>> On Dec 10, 2018, at 7:22 AM, Alice Wonder <[hidden email]> wrote:
>>>
>>> ssl_min_protocol = TLSv1.2
>>> ssl_cipher_list =
>>> EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
>>>
>>> ssl_prefer_server_ciphers = yes
>>
>> The cipherlist syntax is wrong, you're missing a ":" between "!LOW"
>> and "@STRENGTH".
>> My advice is that non-experts should not be asked or attempt to
>> configure explicit
>> TLS cipherlists.  Let the defaults stand, and use software that comes
>> with sensible
>> defaults, upgrading periodically to keep the default configuration
>> current.
>>
>
> You are right there is a typo that didn't get caught.
>
> You are actually wrong that it is better to let defaults stand. With a
> lot of software, upstream doesn't give a damn.
>
> Even in this thread someone pointed out that Debian defaults to 1024-bit
> RSA. You end up with things like SHA1 still enabled because upstream
> thought the compatibility mattered more than the security.
>
> So yes, I made a typo, and maybe I'm not a guru but the reason why I
> fiddle with this stuff is because when I didn't - too often the
> "experts" left things in a way that were dangerous.
>
I'm going to bow out of this thread because an autistic meltdown is
being triggered - not your problem or your fault,

But in the history of experts, never has there ever been an expert who
didn't make typo mistakes along the way to getting there.

Not once.

--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Viktor Dukhovni
In reply to this post by Alice Wonder
> On Dec 10, 2018, at 8:19 PM, Alice Wonder <[hidden email]> wrote:
>
> Even in this thread someone pointed out that Debian defaults to 1024-bit RSA. You end up with things like SHA1 still enabled because upstream thought the compatibility mattered more than the security.
>
> So yes, I made a typo, and maybe I'm not a guru but the reason why I fiddle with this stuff is because when I didn't - too often the "experts" left things in a way that were dangerous.

The dangers of SHA1 and RSA1024 are overhyped.  Walk don't
run to better options when interoperable, and don't set the
bar too high, lest you get reduced security by degrading less
capable peers to cleartext.  There are actors and applications
where SHA1 and RSA1024 may be unwise, but email is mostly not
such an application.  Nobody is investing millions of dollars
in CPU and memory resources to read *your* email traffic.

With TLS, it suffices to raise the ceiling (enable stronger
ciphers) to get strong encryption.  Raising the floor is not
nearly as critical.  Yes, you should have SSLv2 or export
ciphers, but that should not require advanced ciphersuite
settings.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: SSL not working after unwanted server migration

Alice Wonder
On 12/10/18 6:11 PM, Viktor Dukhovni wrote:

>> On Dec 10, 2018, at 8:19 PM, Alice Wonder <[hidden email]> wrote:
>>
>> Even in this thread someone pointed out that Debian defaults to 1024-bit RSA. You end up with things like SHA1 still enabled because upstream thought the compatibility mattered more than the security.
>>
>> So yes, I made a typo, and maybe I'm not a guru but the reason why I fiddle with this stuff is because when I didn't - too often the "experts" left things in a way that were dangerous.
>
> The dangers of SHA1 and RSA1024 are overhyped.  Walk don't
> run to better options when interoperable, and don't set the
> bar too high, lest you get reduced security by degrading less
> capable peers to cleartext.
It is my philosophy that "less is more" with cipher suites that resulted
in 3DES and RC4 being disabled already on my servers (in general, not
just mail servers) long before that was recommended.

It is the fear of the plain text that kept SMTP dangerous for so long,
with expired certs and mis-matched hostnames the norm because why should
an admin bother to keep them accurate when they work?

It is the responsibility of the client to not send if the connection is
not secure, if the client wants to guarantee security for those it sends
for. Using a reduced cipher lists means there is less illusion of
security where it doesn't actually exist.

If the client doesn't support the quality ciphers, it isn't really
secure, so it SHOULD be plain text so that it is obvious it is not
secure. That's my philosophy. It's not a popular philosophy but it is my
philosophy. And with that philosophy, I haven't found myself supporting
known broken ciphers in years. They have been disabled long before the
weaknesses were discovered because I believe less is more.

The cipher list with my typo was Dovecot config, where it doesn't fall
back to plain text with IMAPS. It refuses the connection.


--
For signature trust anchor (paranoid only need worry 'bout this):
https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

Webmail clients, sorry, out of luck, you can't import it.
Get an actual e-mail app.


smime.p7s (4K) Download Attachment
12