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.2ssl_cipher_list = EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4:!ADH:!LOW@STRENGTH
ssl_prefer_server_ciphers = yesThat 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 <al...@domblogger.net> ha scritto:When trouble shooting on systems with SELinux I put it in permissive mode - setenforce 0this 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, MarcoPostfix 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 <racu...@gmail.com> 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, MarcoOn 10 Dec 2018, at 8:08 am, Marco Fioretti <marco.fiore...@gmail.com> 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
Description: S/MIME Cryptographic Signature
