just built new perfect server centos 8 and I'm seeing in maillog: t 25 07:24:17 ns10 postfix/smtpd[192450]: SSL_accept error from mta182s3.r.groupon.com[50.115.222.182]: -1 Oct 25 07:24:17 ns10 postfix/smtpd[192450]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:308: Oct 25 07:25:07 ns10 postfix/smtpd[192667]: SSL_accept error from mta75s3.r.groupon.com[50.115.222.75]: -1 Oct 25 07:25:07 ns10 postfix/smtpd[192667]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:308: Oct 25 07:25:46 ns10 postfix/smtpd[192378]: SSL_accept error from mta139s3.r.groupon.com[50.115.222.139]: -1 Oct 25 07:25:46 ns10 postfix/smtpd[192378]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:308: any idea what is needed?? cdb.
hmm from what I see this may not be an issue seems the server rejected reconnects without getting the SSL error: 50.115.222.182 has the accept error losts connection then connects later gets an NOQUEUE then generates packet 04C9130004CA5 so it looks like they reconnect without generating the SSL error. can I safely ignore it? or is there a better solution? cdb. --snip-- Oct 25 07:24:17 ns10 postfix/smtpd[192450]: connect from mta182s3.r.groupon.com[50.115.222.182] Oct 25 07:24:17 ns10 postfix/smtpd[192450]: SSL_accept error from mta182s3.r.groupon.com[50.115.222.182]: -1 Oct 25 07:24:17 ns10 postfix/smtpd[192450]: warning: TLS library problem: error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:308: Oct 25 07:24:17 ns10 postfix/smtpd[192450]: lost connection after STARTTLS from mta182s3.r.groupon.com[50.115.222.182] Oct 25 07:24:17 ns10 postfix/smtpd[192450]: disconnect from mta182s3.r.groupon.com[50.115.222.182] ehlo=1 starttls=0/1 commands=1/2 Oct 25 07:24:17 ns10 postfix/smtpd[192450]: connect from mta182s3.r.groupon.com[50.115.222.182] Oct 25 07:24:18 ns10 postfix/smtpd[192450]: NOQUEUE: filter: RCPT from mta182s3.r.groupon.com[50.115.222.182]: <[email protected]>: Sender address triggers FILTER amavis:[127.0.0.1]:10026; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mta182s3.r.groupon.com> Oct 25 07:24:18 ns10 postfix/smtpd[192450]: NOQUEUE: filter: RCPT from mta182s3.r.groupon.com[50.115.222.182]: <[email protected]>: Sender address triggers FILTER amavis:[127.0.0.1]:10024; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mta182s3.r.groupon.com> Oct 25 07:24:18 ns10 postfix/smtpd[192450]: 04C9130004CA15: client=mta182s3.r.groupon.com[50.115.222.182] Oct 25 07:24:18 ns10 postfix/cleanup[192383]: 04C9130004CA15: message-id=<1281054189.18306008.1603625056902.JavaMail.rocketman@push-dispatcher62.sac1> Oct 25 07:24:18 ns10 postfix/qmgr[3756732]: 04C9130004CA15: from=<[email protected]>, size=143764, nrcpt=1 (queue active) Oct 25 07:24:19 ns10 postfix/smtpd[192386]: connect from localhost[127.0.0.1] Oct 25 07:24:19 ns10 postfix/smtpd[192386]: E4CF930006B59C: client=localhost[127.0.0.1] Oct 25 07:24:19 ns10 postfix/cleanup[192383]: E4CF930006B59C: message-id=<1281054189.18306008.1603625056902.JavaMail.rocketman@push-dispatcher62.sac1> Oct 25 07:24:19 ns10 postfix/qmgr[3756732]: E4CF930006B59C: from=<[email protected]>, size=144338, nrcpt=1 (queue active) Oct 25 07:24:19 ns10 postfix/smtpd[192386]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5 Oct 25 07:24:19 ns10 dovecot[4133046]: lmtp(192453): Connect from local Oct 25 07:24:19 ns10 amavis[4136757]: (4136757-19) Passed CLEAN {RelayedInbound}, [50.115.222.182]:4745 [50.115.222.182] <[email protected]> -> <[email protected]>, Queue-ID: 04C9130004CA15, Message-ID: <1281054189.18306008.1603625056902.JavaMail.rocketman@push-dispatcher62.sac1>, mail_id: 7n-ztqogmKTk, Hits: -5.664, size: 143762, queued_as: E4CF930006B59C, dkim_sd=s2048d20190430:r.groupon.com, 1242 ms Oct 25 07:24:19 ns10 postfix/smtp[192384]: 04C9130004CA15: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.1, delays=0.84/0/0/1.2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as E4CF930006B59C) Oct 25 07:24:19 ns10 postfix/qmgr[3756732]: 04C9130004CA15: removed --snip--
This means they are trying to connect with a protocol that not enabled in Postfix. In this case SSLv3. You should NOT enable that, as it is insecure. And even if you do enable it in the Postfix config, OpenSSL has it disabled by default aswell. It could be that they tried TLSv1 or TLSv1.1 first and because that failed, they tried SSLv3. TLSv1 and TLSv1.1 does not work in 3.2 because there are no ciphers for them in the Postfix config. You can add them: Code: nano /etc/postfix/main.cf And then replacing Code: tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 tls_preempt_cipherlist = no with Code: tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA tls_preempt_cipherlist = yes Or simply reconfiguring services when you upgrade to 3.2.1, which should be out next week. As the email was delivered, you shouldn't worry about it too much PS: I removed the personal email address from your comment, for privacy reasons.
I left the personal address there just to demonstrate it was infact delivered. thanks for removal. i"ll wait till 3.2.1 cdb.
any Ideas on why I could not ssl connect with the migration tool? any place API login errors are logged so I can try and find out?? told this is the place to ask rather than migration support
target panel DOES have valid cert - visit ns10.cdbsystems.com:8080 (I turned SSL back on). now ns10.cdbsystems.com (on 80 not 8080) does NOT have a good SSL cert. not sure why. I added a vhost to cdbsystems.com for ns10 with lets encrypt. (didnt make a difference) migrate log does not offer any info! 2020-10-25 17:05:29 - [ERROR] Could not log in to api at http://ns10.cdbsystems.com:8080/remote/ with user migrateuser. 2020-10-25 17:05:43 - [ERROR] Error opening connection to ns10.cdbsystems.com on port 8080: 2020-10-25 17:05:43 - [ERROR] JSON API ERROR in API call (login): NO ACCESS 2020-10-25 17:05:43 - [INFO] Trying again (login) 2020-10-25 17:05:46 - [ERROR] Error opening connection to ns10.cdbsystems.com on port 8080: 2020-10-25 17:05:46 - [ERROR] JSON API ERROR in API call (login): NO ACCESS 2020-10-25 17:05:46 - [INFO] Trying again (login) 2020-10-25 17:05:48 - [ERROR] Error opening connection to ns10.cdbsystems.com on port 8080: 2020-10-25 17:05:48 - [ERROR] JSON API ERROR in API call (login): NO ACCESS 2020-10-25 17:05:48 - [ERROR] API call to login failed. 2020-10-25 17:05:48 - [ERROR] JSON API ERROR. Arguments sent were: array ( 'username' => 'migrateuser', 'password' => 'correctpassword!', ) 2020-10-25 17:05:48 - [ERROR] Could not log in to api at https://ns10.cdbsystems.com:8080/remote/ with user migrateuser. where to look on ns10 to see if there is any info on this error???
In the first line it says http:// was used, then later https:// I see that there is a valid cert now. Are there any other lines in the log with a error?
Sorry didnt edit logs right API calls fail both when giving http OR https Didnt add the couple extra lines after https attempt both attempts fail with same error and return same and correct user/pw array If i disable ssl on ispconfig.vhost Then http login works and migration proceeds So how do i locate and fix the problen?
Did you modify anything else in the ISPConfig vhost or global apache config? Can you share the vhost?
no here is ispconfig.vhost (SSL part): Code: <IfModule mod_security2.c> SecRuleEngine Off </IfModule> # SSL Configuration SSLEngine On SSLProtocol All -SSLv3 -TLSv1 -TLSv1.1 SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt SSLCertificateKeyFile /usr/local/ispconfig/interface/ssl/ispserver.key #SSLCACertificateFile /usr/local/ispconfig/interface/ssl/ispserver.bundle SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder On <IfModule mod_headers.c> # ISPConfig 3.1 currently requires unsafe-line for both scripts and styles, as well as unsafe-eval Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:; object-src 'none'" Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:; object-src 'none'; upgrade-insecure-requests" Header set X-Content-Type-Options: nosniff Header set X-Frame-Options: SAMEORIGIN Header set X-XSS-Protection: "1; mode=block" Header always edit Set-Cookie (.*) "$1; HTTPOnly" Header always edit Set-Cookie (.*) "$1; Secure" <IfVersion >= 2.4.7> Header setifempty Strict-Transport-Security "max-age=15768000" </IfVersion> <IfVersion < 2.4.7> Header set Strict-Transport-Security "max-age=15768000" </IfVersion> RequestHeader unset Proxy early </IfModule> SSLUseStapling On SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors Off
one other quick question - is there a clever ispconfig3 way to send a email to ALL current email boxes? ns9 will get retired, so anyone using ns9.cdbsystems.com as the mail host needs to change. alas, I used to have mail.oneofmydomains.com as the MX record - which would move over to ns10 just fine with DNS change - but cant do that these days because mail.xxxx.com does not have its OWN ssl cert - so cant do TLS/SSL connections. wish mail.oneofmydomains.com COULD have its own SSL - maybe in a future release of ispconfig??
Did the source server support TLSv1.2? No, there is not. But you could go into the db, copy the column with adresses for that server, and paste that in your mail client. Or export the table as csv and importing it to your newsletter software. You can add the domain to the cert by adding mail.oneofmydomains.com as aliasdomain to the website you use the cert from for your mailserver. Personally, I use separate servers for web, but all my clients use imap.mycompany.com and smtp.mycompany.com to connect to our mailservers.
this is getting very annoying. I do NOT see where NS10 is getting the bogus cert until now... now ns10 is mentioned in httpd.conf the default server is ns10.cdbsystems.com. but in sites-available ns10.cdbsystems.com its point corrected to an letsencrypt cert. but in the ssl.conf in /etc/httpd/conf.d we have uncommented SSL cert and key files, and thats what is being served in place of the lets encrypt. now with all the vhost files, should the ssl.conf file even be there?? and also - unlike all the other sites I have - ns10.cdbsystems.com le cert points to fullchain.pem NOT cert.pem like the other??? from the vhost file: # </IfModule> SSLCertificateFile /var/www/clients/client0/web21/ssl/ns10.cdbsystems.com-le.crt SSLCertificateKeyFile /var/www/clients/client0/web21/ssl/ns10.cdbsystems.com-le.key but from my directory /ssl---- lrwxrwxrwx 1 root root 46 May 13 2018 cdbsystems.com-le.bundle -> /etc/letsencrypt/live/cdbsystems.com/chain.pem lrwxrwxrwx 1 root root 45 May 13 2018 cdbsystems.com-le.crt -> /etc/letsencrypt/live/cdbsystems.com/cert.pem lrwxrwxrwx 1 root root 48 May 13 2018 cdbsystems.com-le.key -> /etc/letsencrypt/live/cdbsystems.com/privkey.pem lrwxrwxrwx 1 root root 51 Oct 26 09:12 ns10.cdbsystems.com-le.bundle -> /etc/letsencrypt/live/ns10.cdbsystems.com/chain.pem -r-------- 1 root root 1647 Oct 26 09:12 ns10.cdbsystems.com-le.bundle.old.20201026091207 lrwxrwxrwx 1 root root 55 Oct 26 09:12 ns10.cdbsystems.com-le.crt -> /etc/letsencrypt/live/ns10.cdbsystems.com/fullchain.pem -r-------- 1 root root 2269 Oct 26 09:12 ns10.cdbsystems.com-le.crt.old.20201026091207 lrwxrwxrwx 1 root root 53 Oct 26 09:12 ns10.cdbsystems.com-le.key -> /etc/letsencrypt/live/ns10.cdbsystems.com/privkey.pem -r-------- 1 root root 3272 Oct 26 09:12 ns10.cdbsystems.com-le.key.old.20201026091207 lrwxrwxrwx 1 root root 50 Oct 14 09:28 ns9.cdbsystems.com-le.bundle -> /etc/letsencrypt/live/ns9.cdbsystems.com/chain.pem -r-------- 1 root root 1647 Sep 1 14:35 ns9.cdbsystems.com-le.bundle.old.20200901143519 -r-------- 1 root root 1647 Oct 14 09:28 ns9.cdbsystems.com-le.bundle.old.20201014092806 lrwxrwxrwx 1 root root 49 Oct 14 09:28 ns9.cdbsystems.com-le.crt -> /etc/letsencrypt/live/ns9.cdbsystems.com/cert.pem -r-------- 1 root root 2269 Sep 1 14:35 ns9.cdbsystems.com-le.crt.old.20200901143519 -r-------- 1 root root 2269 Oct 14 09:28 ns9.cdbsystems.com-le.crt.old.20201014092806 lrwxrwxrwx 1 root root 52 Oct 14 09:28 ns9.cdbsystems.com-le.key -> /etc/letsencrypt/live/ns9.cdbsystems.com/privkey.pem -r-------- 1 root root 3272 Sep 1 14:35 ns9.cdbsystems.com-le.key.old.20200901143519 -r-------- 1 root root 3272 Oct 14 09:28 ns9.cdbsystems.com-le.key.old.20201014092806 note that ns10.cdbsystems.com-le-crt points to fullchain.pem, but ns9.cdbsystems.com-le.crt points to cert.pem only? in other ssl folder where ssl works fine, they all point to cert not fullchain. so... why the screwed up situation? did I miss a line 'disable ssl.conf' in the perfect centos 8 tutoral? obviously I could change the ssl.conf entries or change localhost.crt to be a symlink to letsencrypt. but I wonder where I missed the boat? thanks
so in conclusion, I went back to the ssl.conf file when I setup the old server years ago - and lo and behold - EVERYTHING after ##SSL Virtual Host Context was deleted! so that this whole ssl mess could have been prevented if I had deleted it on the new server. when we have the *.vhost files, there is no need for a <Virtual Host> defined within ssl.conf. and all it can actually do is .... cause confusion and consternation! Did I miss this from the tutorial? if I did not it should surely be there! I would suggest before 7. Install Dovecot we add: edit the default ssl.conf - /etc/httpd/conf.d/ssl.conf and delete EVERYTHING after # SSL Virtual Host Context and systemctl restart httpd --end of snip. and sadly, doing this does NOT fix the migration problem the API login fails unless SSL is disabled on ispconfig.vhost. and no --legacy-tls does not help. would be happy to help try and track this down! cdb.
Really, you should not waste time for this. Just disable SSL during migration and then re-enable it. It might be that your source servers' PHP is not able to connect to the target TLS/SSL version. So trying to solve that at all cost – while it is only(!) relevant during migration – is useless, imho.
