I've had a Ubuntu 14.04 server configured and running fine for some time now. There are web, ftp and mail server installed and functioning properly on it. A week ago the SSL certificate that I had been using to connect to the management console and for mail expired and I went ahead and acquired a new one from StartSSL.
The new certificate is for mail.mydomain.com. The Postfix (main.cf) configuration contains the following:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = /usr/share/doc/postfix
# TLS parameters
smtpd_tls_cert_file = /etc/postfix/mail.crt
smtpd_tls_key_file = /etc/postfix/mail.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
myhostname = mail.mysite.com
alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
myorigin = /etc/mailname
mydestination = mail.mysite.eu, localhost, localhost.localdomain
Dovecot.conf
protocols = imap pop3
auth_mechanisms = plain login
disable_plaintext_auth = no
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_privileged_group = vmail
postmaster_address = postmaster#saturn13.eu
ssl_cert = </etc/postfix/mail.crt
ssl_key = </etc/postfix/mail.key
ssl_protocols = !SSLv2 !SSLv3
Dovecot/conf.d/10-ssl.conf
ssl = yes
ssl_cert = </etc/postix/mail.crt
ssl_key = </etc/postfix/mail.key
I read that StartSSL requires an intermediate and root CA to be installed, so I tried concatenating them into a mail.pem file which I then proceeded to set in both Postfix and Dovecot. Try as I might, every time I ran openSSL test, the results were like this:
root#server:/etc/dovecot# openssl s_client -connect mail.mysite.com:465
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
What's even more puzzling for me is the fact that when I try to connect to the account with Thunderbird, a popup window appears asking to confirm a security exception for www.mysite.com:443.
So, could you help me figure out what's wrong in this configuration? When I open the mail.crt file in Windows, everything appears normal. So why can't I connect to the server and why is Thunderbird trying to connect to www and on port 443?
Thank you!
with startssl certs you need to wait for one day or ocsp validating will fail.
firefox and thunderbird have ocsp enabled. maybe this was the cause for TB...
for the openssl error, maybe you are using the wrong ciphers? Check here: https://weakdh.org/sysadmin.html
your mail.crt looks like:
-----BEGIN CERTIFICATE-----
..xxx..
-----END CERTIFICATE-----
and your mail.key like
-----BEGIN RSA PRIVATE KEY-----
...xxx...
-----END RSA PRIVATE KEY-----
you don't need to install startssl root cert as it is installed in all browsers...
just the intermediate:
for postfix i'm using
smtpd_tls_CAfile = /etc/ssl/private/sub.class1.server.ca.pem
for dovecot
ssl_ca = </etc/ssl/private/sub.class1.server.ca.pem
and apache
SSLCertificateChainFile /etc/ssl/private/sub.class1.server.ca.pem
Related
Has anyone successfully set up msmtp with a Mailgun account? I keep getting "Relaying denied", and msmtp reports that the envelope from is invalid. I have tried every variation of the from address that I can think of, scoured Mailgun's documentation for details on their SMTP parameters, and searched the web for examples, and I've not found anything that differs from my setup (aside from server and account names, of course).
Here is my /etc/msmtprc file,
account default
# The SMTP smarthost
host smtp.mailgun.org
# Use TLS on port 465
port 465
tls on
tls_starttls off
user manul#mail.mydomain.net
password [snip]
from mailgun#mydomain.net
# Syslog logging with facility LOG_MAIL instead of the default LOG_USER
syslog LOG_MAIL
And the msmtp session:
$ echo 'Subject: Grfg' | msmtp -v 'aidalgol#example.net'
loaded system configuration file /etc/msmtprc
ignoring user configuration file /home/me/.msmtprc: No such file or directory
falling back to default account
using account default from /etc/msmtprc
host = smtp.mailgun.org
port = 465
source ip = (not set)
proxy host = (not set)
proxy port = 0
timeout = off
protocol = smtp
domain = localhost
auth = none
user = manul#mail.mydomain.net
password = *
passwordeval = (not set)
ntlmdomain = (not set)
tls = on
tls_starttls = off
tls_trust_file = system
tls_crl_file = (not set)
tls_fingerprint = (not set)
tls_key_file = (not set)
tls_cert_file = (not set)
tls_certcheck = on
tls_min_dh_prime_bits = (not set)
tls_priorities = (not set)
auto_from = off
maildomain = (not set)
from = mailgun#aidalgolland.net
add_missing_from_header = on
add_missing_date_header = on
remove_bcc_headers = on
dsn_notify = (not set)
dsn_return = (not set)
logfile = (not set)
logfile_time_format = (not set)
syslog = LOG_MAIL
aliases = (not set)
reading recipients from the command line
TLS session parameters:
(TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM)
TLS certificate information:
Owner:
Common Name: *.mailgun.org
Organization: MAILGUN TECHNOLOGIES\, INC
Organizational unit: MAILGUN TECHNOLOGIES\, INC
Locality: San Francisco
State or Province: California
Country: US
Issuer:
Common Name: Thawte TLS RSA CA G1
Organization: DigiCert Inc
Organizational unit: www.digicert.com
Country: US
Validity:
Activation time: Wed 19 Feb 2020 13:00:00 NZDT
Expiration time: Wed 20 Apr 2022 00:00:00 NZST
Fingerprints:
SHA256: 9E:5F:9B:27:BB:26:14:6F:3E:2F:50:75:FE:BF:64:1C:4B:8D:E0:A6:B7:EA:4F:27:13:05:FD:81:3F:57:52:26
SHA1 (deprecated): 54:36:F6:D1:44:0A:B4:62:F0:94:1B:21:7A:1B:82:5C:DF:FD:FF:57
<-- 220 Mailgun Influx ready
--> EHLO localhost
<-- 250-smtp-out-n17.prod.us-east-1.postgun.com
<-- 250-AUTH PLAIN LOGIN
<-- 250-SIZE 52428800
<-- 250-8BITMIME
<-- 250-ENHANCEDSTATUSCODES
<-- 250-SMTPUTF8
<-- 250 PIPELINING
--> MAIL FROM:<mailgun#myexample.net>
--> RCPT TO:<aidalgol#example.net>
--> DATA
<-- 550 5.7.1 Relaying denied
msmtp: envelope from address mailgun#mydomain.net not accepted by the server
msmtp: server message: 550 5.7.1 Relaying denied
msmtp: could not send mail (account default from /etc/msmtprc)
It turned out to be that I needed to set auth on in the msmtp configuration. The error envelope from address mailgun#mydomain.net not accepted by the server from msmtp was completely wrong.
For other people who got here you'll probably need to go to
https://app.mailgun.com/app/sending/domains/**YOUR-DOMAIN-NAME-HERE/credentials
to get your per-domain credentials as suggested here:
https://documentation.mailgun.com/en/latest/quickstart-sending.html#send-via-api
I diagrammed what to put where in the configuration file along with how to navigate to the setting. This should help make things super clear hopefully.
Note: The grey info-box in the bottom right with the password copy thing I got to by clicking on the green outlined "Reset password" button
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
I am using sendmail in node.js to send Emails. my mail server is postfix.
my TLS parameters in postfix config file is like this:
# TLS parameters
smtpd_tls_cert_file = /home/avanel/CMS/Render/ipeccongress_com.crt
smtpd_tls_key_file = /home/avanel/CMS/Render/capk.txt
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
BTW i used my SSL certificate and key (I mean same as https).
but when receive gmail says is not encrypted. what is wrong?
I have the following results in certificate validation problems:
use URI;
use Web::Scraper
my $res = $scraper->scrape( URI->new('https://example.com') );
After waiting about 2 min, I get the following error:
GET https://example.com failed: 500 Can't connect to example.com:443
(certificate verify failed)
Per suggestion in comments, I ran openssl s_client -connect olms.dol-esa.gov:443. It output the following to the terminal instantly and then hung for about 2 minutes:
CONNECTED(00000003)
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=olms.dol-esa.gov/O=DEPARTMENT OF LABOR/L=Washington/ST=District of Columbia/C=US
i:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
1 s:/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
i:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
2 s:/C=US/O=IdenTrust/CN=IdenTrust Commercial Root CA 1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
3 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
<SNIP>
-----END CERTIFICATE-----
subject=/CN=olms.dol-esa.gov/O=DEPARTMENT OF LABOR/L=Washington/ST=District of Columbia/C=US
issuer=/C=US/O=IdenTrust/OU=TrustID Server/CN=TrustID Server CA A52
---
No client certificate CA names sent
---
SSL handshake has read 6233 bytes and written 615 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DES-CBC3-SHA
Session-ID: 3E5B2FBD819EF7880143C874181B7D67D3B1A0CE7C319B35F276E1CE8D9B9A18
Session-ID-ctx:
Master-Key: BE8A24B0350C48FCC3ECFA21AE896BF09F8978C481F3BE01E1E9B904A0BFB87098914DB6CD592BBC7634142A4B5C43FB
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1486034348
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
After waiting about two minutes, the following was output:
read:errno=0
Web::Scraper uses LWP::UserAgent. More modern versions of that attempt to verify the hostnames unless you turn off that feature. Something else may be going on, but this question is low in details.
One of the constructor arguments to LWP::UserAgent is:
LWP::UserAgent->new(
ssl_opts => { verify_hostname => 0 }
...;
}
You can construct your own user agent object and give it to Web::Scraper:
my $scraper = Web::Scraper->new(...);
$scraper->user_agent( $your_own_lwp_useragent_object );
Also see the answer at "Perl LWP::Simple HTTPS error". For more help, we'll need version details for the relevant modules and your openssl details.
I have two machines, one running Ubuntu and one runing Debian, both running Postfix. The intent is that machine#2 becomes a SMTP relay/smarthost for machine#1. I have created a CA and issued certificates for both of the machines: a server certificate for #2 and a client certificate for #1.
When sending e-mail from #1 (by having the MUA talk to Postfix on localhost:25 with the intent that it relays e-mail to #2), the basic things work fine: the machines can talk to each other and an attempt to relay is actually made. The idea is to allow relaying on #2 if a valid client-side SSL/TLS certificate is presented from #1.
The relevant configuration for #2 is:
smtpd_tls_received_header = yes
smtpd_tls_loglevel = 2
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/ssl/private/cert2.pem
smtpd_tls_key_file = /etc/ssl/private/key2-d.pem
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_auth_only = yes
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination permit_tls_all_clientcerts
The configuration on #1 is:
smtp_tls_CAfile = /etc/ssl/certs/cacert.pem
smtp_tls_cert_file = /etc/ssl/private/cert1.pem
smtp_tls_key_file = /etc/ssl/private/key1-d.pem
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_security_level = verify
smtp_tls_loglevel = 2
Machine#1 connects to #2, enables STARTTLS, the log files show that it successfuly verifies the certificate from #2, and attempts to relay the message. However, it appears not to send the client certificate to #2, and #2 refuses to relay the message.
Log entries from #1:
Apr 17 01:18:14 mail1 postfix/smtp[30250]: Verified TLS connection established to mail2[x.x.x.x]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 17 01:18:14 mail1 postfix/smtp[30244]: 8A2328BDB4: to=<addr#gmail.com>, relay=mail2[x.x.x.x]:25, delay=3488, delays=3486/0.41/0.85/0.19, dsn=4.7.1, status=deferred (host mail2[x.x.x.x] said: 454 4.7.1 <addr#gmail.com>: Relay access denied (in reply to RCPT TO command))
Log entries from #2:
Apr 17 01:18:13 mail2 postfix/smtpd[28798]: Anonymous TLS connection established from unknown[y.y.y.y]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 17 01:18:13 mail2 postfix/smtpd[28798]: NOQUEUE: reject: RCPT from unknown[y.y.y.y]: 454 4.7.1 <addr#gmail.com>: Relay access denied; from=<addr#mail1> to=<addr#gmail.com> proto=ESMTP helo=<mail1>
Any ideas? I'm basing my assumption that #1 didn't send its client cert on the "Anonymous TLS connection established" part in the logs from mail2.
A TLS server must request a certificate from the client, the client will not send it by its own. Try to add
smtpd_tls_ask_ccert=yes
on the server side
add your server adress ( server1.domaine.com ) in the postfix conf file main.cf
mynetworks = 127.0.0.1/8