Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Problem configure SMTPs with TLS in sendmail
440 views
Skip to first unread message
cerna....@gmail.com
Apr 25, 2019, 2:36:23 PM4/25/19
to
The SSL certificate was configured following the steps of the link https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000zFI6 this with the Finalidar of configuring the service of SendMail with TLS but when performing one of sending of e-mail and another test of telnet to the TCP port 465 shows me the error messages SendMail TLS deferred: Connection rejected by [127.0.0.1] and 454 4.3.3 TLS not available: Error generating SSL handle
The SendMail service is installed on a Solaris 11.3 operating system server, this server does not have the firewall enabled.
I expect your early support.
The SendMail service is installed on a Solaris 11.3 operating system server, this server does not have the firewall enabled.
I expect your early support.
Grant Taylor
Apr 25, 2019, 3:32:21 PM4/25/19
to
On 4/25/19 12:36 PM, cerna....@gmail.com wrote:
> The SSL certificate was configured following the steps of the link
> https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000zFI6
> this with the Finalidar of configuring the service of SendMail with TLS
That is a minimal How To. It just tells you want to do and not why or
> The SSL certificate was configured following the steps of the link
> https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000zFI6
> this with the Finalidar of configuring the service of SendMail with TLS
how. :-/
> but when performing one of sending of e-mail and another test of telnet
> to the TCP port 465 shows me the error messages SendMail TLS deferred:
> Connection rejected by [127.0.0.1] and 454 4.3.3 TLS not available:
> Error generating SSL handle
Clarify if you are wanting Sendmail to be the /server/ offering Secure
Submission to connecting clients or if you are wanting Sendmail to use
use security when it's the /client/ sending to other servers.
Note: You can't fully test Secure Submission on TCP port 465 with
(basic) telnet. You need to use OpenSSL or something comparable.
openssl s_client -host host.example.net -port 465
> The SendMail service is installed on a Solaris 11.3 operating system
> server, this server does not have the firewall enabled.
> I expect your early support.
their time. "hope" / "anticipate" / "await". But not "expect".
--
Grant. . . .
unix || die
cerna....@gmail.com
Apr 26, 2019, 11:47:43 AM4/26/19
to
Hello Taylor,
I detail the inconvenience that I am having.
When I set up a certificate signed by a certifying entity so that my mailings go out with TLS in my system logs, it shows me the message:
stat = Deferred: Connection refused by [127.0.0.1]
To discard that my problem is for the SSL certificate, I have proceeded to create a local certificate and configure it in my mc file to compile it later.
When sending tests, I notice in the mail header that the TLS protocol is visible but not verified (this is because it is a local certificate)
Received: from smtp.escondatagate.com.pe (localhost [127.0.0.1]) by smtp.escondatagate.com.pe (8.15.1 + Sun / 8.15.1) with ESMTPS id x3Q5BQib021106 (version = TLSv1.2 cipher = DHE -RSA-AES256-GCM-SHA384 bits = 256 verify = NO) for <kcar...@esconcorp.com>; Fri, 26 Apr 2019 00:11:26 -0500 (PET)
With this I am deducting that my problem goes through an issue of the acquired SSL certificate and not the configuration of the sendmail, what do you think?
I am sending you the result of executing the openssl command (this test was done with the SSL certificate of SSL2BUY)
oot@mail2:/etc/mail/cf/cf# openssl s_client -host smtp.escondatagate.com.pe -port 465
CONNECTED(00000004)
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=PE/OU=Domain Control Validated/CN=smtp.escondatagate.com.pe
i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
i:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF+zCCBOOgAwIBAgIMPMZ0U3B1Z1X2YhZtMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE5MDQxNjAzMDcxN1oXDTIwMDQx
NjAzMDcxN1owVDELMAkGA1UEBhMCUEUxITAfBgNVBAsTGERvbWFpbiBDb250cm9s
IFZhbGlkYXRlZDEiMCAGA1UEAxMZc210cC5lc2NvbmRhdGFnYXRlLmNvbS5wZTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKM2359/ROzLvkqAthwyC2tn
a5GIFp3UNJrLce/o52R3RFipb8wxZ1u7rSj8GUR2LpYJ3joKoAR6twCoWXXqJ/PC
FX8lFPlBufa6R6Ils6oZp2BZWouKQxXmrSQKRCsE+h9/DDiYPXwINp4BCI88FPsA
yOsd9uBmngE8iTKDb6sk8c0lrxJVSQJRAmLztpwKLnw/bzSWtFk180n4b+KGq5uH
iB1kR2fL6852hYqxQtsaKUj8Z8IS7aByzlL/xpe3yDrgSNFe0GyXlURNu4u9F7iw
fCe4Ft3pjAkoF8eVYHTR3aqtGTA1fUX1uoAJ8qLwn05+2yrppCzXbI8SpeY2ucMC
AwEAAaOCAtMwggLPMA4GA1UdDwEB/wQEAwIFoDCBiQYIKwYBBQUHAQEEfTB7MEIG
CCsGAQUFBzAChjZodHRwOi8vc2VjdXJlMi5hbHBoYXNzbC5jb20vY2FjZXJ0L2dz
YWxwaGFzaGEyZzJyMS5jcnQwNQYIKwYBBQUHMAGGKWh0dHA6Ly9vY3NwMi5nbG9i
YWxzaWduLmNvbS9nc2FscGhhc2hhMmcyMFcGA1UdIARQME4wQgYKKwYBBAGgMgEK
CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBv
c2l0b3J5LzAIBgZngQwBAgEwCQYDVR0TBAIwADA+BgNVHR8ENzA1MDOgMaAvhi1o
dHRwOi8vY3JsMi5hbHBoYXNzbC5jb20vZ3MvZ3NhbHBoYXNoYTJnMi5jcmwwJAYD
VR0RBB0wG4IZc210cC5lc2NvbmRhdGFnYXRlLmNvbS5wZTAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFAX7K0c9EyIvgT5WUvy9U3smL6bO
MB8GA1UdIwQYMBaAFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MIIBBgYKKwYBBAHWeQIE
AgSB9wSB9ADyAHcAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFq
JBz12AAABAMASDBGAiEA/ItIEVHrDMIxXPS8DX79q7J5vhZ2uukGr68z1GF6afUC
IQCRL2sCGqvuykRxRwBvSynKrONIx67qTiSvxQrMnBv8KQB3AG9Tdqwx8DEZ2JkA
pFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaiQc9YcAAAQDAEgwRgIhAOAGUEwyTPaz
QvSE/jQ3ztxjQA6xoLiswOF4euuCHcQWAiEAvJkgjfkXTOJWxDa285cnUCmE35a1
93bnyAEkdeO0Nm8wDQYJKoZIhvcNAQELBQADggEBAKBVe6NL+Fx9YKBeLDmPJ7mC
XtMP/BGh+BIfUGhU0FPEWdHh7ndi3Z6GiPbcb9yFECJHNQcAwicIsi0YuRgGvueQ
q7tmafgEiq5wJpZ40stpsMN0tisfuVvhQm7k1y3ANhQsga/tC6k9F7QfM09Srs8n
OIg2CSOCUUfNeB9ImHHGjBQU8CLqpB7czZLZdDToFSPXJWFIDgKgMBrkecYceBT/
Oqe+cdb0D3UZGVeBN83J1oLsPCbyn7ZOM2cSo3rpLmkdKXuFShkMntEmI6lcS/Si
2HKKh9XTilFpaE8+AjeGEbm4NSIqwSvYECm0Bso/aMsj7ZpZErHr7meWbWhFaVs=
-----END CERTIFICATE-----
subject=/C=PE/OU=Domain Control Validated/CN=smtp.escondatagate.com.pe
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
Acceptable client certificate CA names
/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
SSL handshake has read 3817 bytes and written 353 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 2106113511D49F87C95FE2353C7437B439A24B380CDCCFB1251C7D2B01EF2005
Session-ID-ctx:
Master-Key: E73A6150914E72AAE72DE8CF78EAEB113EE12CD446A46BD6535C962CB843AB6D47D4AE95C35523C02D2AFF5C8AC3E07F
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 1 (seconds)
TLS session ticket:
0000 - e4 b5 c8 52 99 4e c9 4a-2d b7 b9 9f 3d 42 dc 26 ...R.N.J-...=B.&
0010 - d5 96 6b f5 9e 52 f4 ee-40 33 9a 74 b1 7f 91 34 ..k..R..@3.t...4
0020 - 18 32 31 27 9b 21 2d ac-a1 eb 52 a0 18 2d d1 76 .21'.!-...R..-.v
0030 - e6 75 50 03 ff e2 59 5f-f7 39 f7 34 dd af db ea .uP...Y_.9.4....
0040 - 68 9d b1 47 9c f7 b5 d0-55 6b 8b 92 50 ba 29 30 h..G....Uk..P.)0
0050 - ed ed 3f 37 15 c8 3e 0b-23 43 5d d4 d9 40 31 23 ..?7..>.#C]..@1#
0060 - fc 45 3f f7 dd 81 45 39-ab dc fe c9 a8 97 61 6a .E?...E9......aj
0070 - 65 8c fb 90 2e a6 f6 fd-65 c3 9e fb 68 7b 19 2b e.......e...h{.+
0080 - eb 7d 62 49 75 5d c9 9d-6b ec 2f 6b 09 af fe 8c .}bIu]..k./k....
0090 - ec 4e 34 36 c0 44 d1 7f-af cb b7 94 6d 41 0c 1d .N46.D......mA..
Start Time: 1556251384
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
220 smtp.escondatagate.com.pe ESMTP Sendmail 8.15.1+Sun/8.15.1; Thu, 25 Apr 2019 23:03:04 -0500 (PET)
I detail the inconvenience that I am having.
When I set up a certificate signed by a certifying entity so that my mailings go out with TLS in my system logs, it shows me the message:
stat = Deferred: Connection refused by [127.0.0.1]
To discard that my problem is for the SSL certificate, I have proceeded to create a local certificate and configure it in my mc file to compile it later.
When sending tests, I notice in the mail header that the TLS protocol is visible but not verified (this is because it is a local certificate)
Received: from smtp.escondatagate.com.pe (localhost [127.0.0.1]) by smtp.escondatagate.com.pe (8.15.1 + Sun / 8.15.1) with ESMTPS id x3Q5BQib021106 (version = TLSv1.2 cipher = DHE -RSA-AES256-GCM-SHA384 bits = 256 verify = NO) for <kcar...@esconcorp.com>; Fri, 26 Apr 2019 00:11:26 -0500 (PET)
With this I am deducting that my problem goes through an issue of the acquired SSL certificate and not the configuration of the sendmail, what do you think?
I am sending you the result of executing the openssl command (this test was done with the SSL certificate of SSL2BUY)
oot@mail2:/etc/mail/cf/cf# openssl s_client -host smtp.escondatagate.com.pe -port 465
CONNECTED(00000004)
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=PE/OU=Domain Control Validated/CN=smtp.escondatagate.com.pe
i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
i:/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF+zCCBOOgAwIBAgIMPMZ0U3B1Z1X2YhZtMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE5MDQxNjAzMDcxN1oXDTIwMDQx
NjAzMDcxN1owVDELMAkGA1UEBhMCUEUxITAfBgNVBAsTGERvbWFpbiBDb250cm9s
IFZhbGlkYXRlZDEiMCAGA1UEAxMZc210cC5lc2NvbmRhdGFnYXRlLmNvbS5wZTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKM2359/ROzLvkqAthwyC2tn
a5GIFp3UNJrLce/o52R3RFipb8wxZ1u7rSj8GUR2LpYJ3joKoAR6twCoWXXqJ/PC
FX8lFPlBufa6R6Ils6oZp2BZWouKQxXmrSQKRCsE+h9/DDiYPXwINp4BCI88FPsA
yOsd9uBmngE8iTKDb6sk8c0lrxJVSQJRAmLztpwKLnw/bzSWtFk180n4b+KGq5uH
iB1kR2fL6852hYqxQtsaKUj8Z8IS7aByzlL/xpe3yDrgSNFe0GyXlURNu4u9F7iw
fCe4Ft3pjAkoF8eVYHTR3aqtGTA1fUX1uoAJ8qLwn05+2yrppCzXbI8SpeY2ucMC
AwEAAaOCAtMwggLPMA4GA1UdDwEB/wQEAwIFoDCBiQYIKwYBBQUHAQEEfTB7MEIG
CCsGAQUFBzAChjZodHRwOi8vc2VjdXJlMi5hbHBoYXNzbC5jb20vY2FjZXJ0L2dz
YWxwaGFzaGEyZzJyMS5jcnQwNQYIKwYBBQUHMAGGKWh0dHA6Ly9vY3NwMi5nbG9i
YWxzaWduLmNvbS9nc2FscGhhc2hhMmcyMFcGA1UdIARQME4wQgYKKwYBBAGgMgEK
CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBv
c2l0b3J5LzAIBgZngQwBAgEwCQYDVR0TBAIwADA+BgNVHR8ENzA1MDOgMaAvhi1o
dHRwOi8vY3JsMi5hbHBoYXNzbC5jb20vZ3MvZ3NhbHBoYXNoYTJnMi5jcmwwJAYD
VR0RBB0wG4IZc210cC5lc2NvbmRhdGFnYXRlLmNvbS5wZTAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFAX7K0c9EyIvgT5WUvy9U3smL6bO
MB8GA1UdIwQYMBaAFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MIIBBgYKKwYBBAHWeQIE
AgSB9wSB9ADyAHcAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFq
JBz12AAABAMASDBGAiEA/ItIEVHrDMIxXPS8DX79q7J5vhZ2uukGr68z1GF6afUC
IQCRL2sCGqvuykRxRwBvSynKrONIx67qTiSvxQrMnBv8KQB3AG9Tdqwx8DEZ2JkA
pFEV/3cVHBHZAsEAKQaNsgiaN9kTAAABaiQc9YcAAAQDAEgwRgIhAOAGUEwyTPaz
QvSE/jQ3ztxjQA6xoLiswOF4euuCHcQWAiEAvJkgjfkXTOJWxDa285cnUCmE35a1
93bnyAEkdeO0Nm8wDQYJKoZIhvcNAQELBQADggEBAKBVe6NL+Fx9YKBeLDmPJ7mC
XtMP/BGh+BIfUGhU0FPEWdHh7ndi3Z6GiPbcb9yFECJHNQcAwicIsi0YuRgGvueQ
q7tmafgEiq5wJpZ40stpsMN0tisfuVvhQm7k1y3ANhQsga/tC6k9F7QfM09Srs8n
OIg2CSOCUUfNeB9ImHHGjBQU8CLqpB7czZLZdDToFSPXJWFIDgKgMBrkecYceBT/
Oqe+cdb0D3UZGVeBN83J1oLsPCbyn7ZOM2cSo3rpLmkdKXuFShkMntEmI6lcS/Si
2HKKh9XTilFpaE8+AjeGEbm4NSIqwSvYECm0Bso/aMsj7ZpZErHr7meWbWhFaVs=
-----END CERTIFICATE-----
subject=/C=PE/OU=Domain Control Validated/CN=smtp.escondatagate.com.pe
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
Acceptable client certificate CA names
/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
SSL handshake has read 3817 bytes and written 353 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID: 2106113511D49F87C95FE2353C7437B439A24B380CDCCFB1251C7D2B01EF2005
Session-ID-ctx:
Master-Key: E73A6150914E72AAE72DE8CF78EAEB113EE12CD446A46BD6535C962CB843AB6D47D4AE95C35523C02D2AFF5C8AC3E07F
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 1 (seconds)
TLS session ticket:
0000 - e4 b5 c8 52 99 4e c9 4a-2d b7 b9 9f 3d 42 dc 26 ...R.N.J-...=B.&
0010 - d5 96 6b f5 9e 52 f4 ee-40 33 9a 74 b1 7f 91 34 ..k..R..@3.t...4
0020 - 18 32 31 27 9b 21 2d ac-a1 eb 52 a0 18 2d d1 76 .21'.!-...R..-.v
0030 - e6 75 50 03 ff e2 59 5f-f7 39 f7 34 dd af db ea .uP...Y_.9.4....
0040 - 68 9d b1 47 9c f7 b5 d0-55 6b 8b 92 50 ba 29 30 h..G....Uk..P.)0
0050 - ed ed 3f 37 15 c8 3e 0b-23 43 5d d4 d9 40 31 23 ..?7..>.#C]..@1#
0060 - fc 45 3f f7 dd 81 45 39-ab dc fe c9 a8 97 61 6a .E?...E9......aj
0070 - 65 8c fb 90 2e a6 f6 fd-65 c3 9e fb 68 7b 19 2b e.......e...h{.+
0080 - eb 7d 62 49 75 5d c9 9d-6b ec 2f 6b 09 af fe 8c .}bIu]..k./k....
0090 - ec 4e 34 36 c0 44 d1 7f-af cb b7 94 6d 41 0c 1d .N46.D......mA..
Start Time: 1556251384
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
220 smtp.escondatagate.com.pe ESMTP Sendmail 8.15.1+Sun/8.15.1; Thu, 25 Apr 2019 23:03:04 -0500 (PET)
Grant Taylor
Apr 27, 2019, 2:22:33 PM4/27/19
to
On 4/26/19 9:47 AM, cerna....@gmail.com wrote:
> Hello Taylor,
Hi,
"Grant" is preferred. ;-)
> I detail the inconvenience that I am having.
>
> When I set up a certificate signed by a certifying entity so that my
> mailings go out with TLS in my system logs, it shows me the message:
>
> stat = Deferred: Connection refused by [127.0.0.1]
I would not think that a certificate would cause a connection to be
refused. I would expect that to be a lack of a listening daemon.
I wonder if Sendmail is refusing to start and / or listen on the port in
question because of problems with the certificate. If this is the case,
I would expect log entries to that effect.
> To discard that my problem is for the SSL certificate, I have
> proceeded to create a local certificate and configure it in my mc
> file to compile it later.
That seems like a reasonable thing to do.
Note: I'm successfully using a free Let's Encrypt certificate with
Sendmail.
> When sending tests, I notice in the mail header that the TLS protocol
> is visible but not verified (this is because it is a local certificate)
You can likely get the encryption to verify if you add the Root CA cert
to the receiving system. - It's a minimal amount of work if you care.
But you are going to want a valid trusted cert when talking to servers
that you don't control.
> Received: from smtp.escondatagate.com.pe (localhost [127.0.0.1])
> by smtp.escondatagate.com.pe (8.15.1 + Sun / 8.15.1) with ESMTPS id
> x3Q5BQib021106 (version = TLSv1.2 cipher = DHE -RSA-AES256-GCM-SHA384
> bits = 256 verify = NO) for <kcar...@esconcorp.com>; Fri, 26 Apr
> 2019 00:11:26 -0500 (PET)
>
> With this I am deducting that my problem goes through an issue of the
> acquired SSL certificate and not the configuration of the sendmail,
> what do you think?
I think that you should be able to trade out the certificate file(s)
without needing to change Sendmail. Obviously you will need to restart
Sendmail to have it see and use the changed certificate.
One hack that you can do is to configure Sendmail to use certificate
file(s) that is (are) a symbolic link to the real certificate. Then you
just need to update the symbolic link and restart Sendmail when you want
to switch certificate file(s).
define(`confSERVER_CERT', `/etc/mail/server_cert.current')dnl
define(`confSERVER_KEY', `/etc/mail/server_key.current' )dnl
define(`confCLIENT_CERT', `/etc/mail/client_cert.current')dnl
define(`confCLIENT_KEY', `/etc/mail/client_key.current' )dnl
Then have files like the following:
/etc/mail/client_cert.current -> /etc/mail/client_cert.self-signed
/etc/mail/client_cert.self-signed
/etc/mail/client_cert.trusted-ca
/etc/mail/client_key.current -> /etc/mail/client_key.self-signed
/etc/mail/client_key.self-signed
/etc/mail/client_key.trusted-ca
/etc/mail/server_cert.current -> /etc/mail/server_cert.self-signed
/etc/mail/server_cert.self-signed
/etc/mail/server_cert.trusted-ca
/etc/mail/server_key.current -> /etc/mail/server_key.self-signed
/etc/mail/server_key.self-signed
/etc/mail/server_key.trusted-ca
IMHO this technique (hack) makes it easy to trade out certificates when
they need to be renewed without reconfiguring Sendmail.
1) Copy the new certificate file(s) into place.
2) Update symbolic links.
3) Restart Sendmail.
If everything works when you point to the self-signed files, but fails
with the trusted-ca files, then chances are very good that it's a
problem with the certificate files and not the Sendmail config.
> I am sending you the result of executing the openssl command (this
> test was done with the SSL certificate of SSL2BUY)
>
> root@mail2:/etc/mail/cf/cf# openssl s_client -host smtp.escondatagate.com.pe -port 465
The fact that you're using TCP port 465 tells me that you're using the
Secure Submission port. Which means that Sendmail must be happy with
the certificate to listen.
If you were using TCP port 25 or 587, you might be able to connect but
not see STARTTLS in response to an EHLO.
I'm not sure what Sendmail's failure mode is if everything else is
happy, but has an invalid (wrong format) certificate file.
> 220 smtp.escondatagate.com.pe ESMTP Sendmail 8.15.1+Sun/8.15.1; Thu, 25 Apr 2019 23:03:04 -0500 (PET)
That all looks to me like Sendmail was happy with the certificate and
that TLS was negotiated properly.
> Hello Taylor,
Hi,
"Grant" is preferred. ;-)
> I detail the inconvenience that I am having.
>
> When I set up a certificate signed by a certifying entity so that my
> mailings go out with TLS in my system logs, it shows me the message:
>
> stat = Deferred: Connection refused by [127.0.0.1]
refused. I would expect that to be a lack of a listening daemon.
I wonder if Sendmail is refusing to start and / or listen on the port in
question because of problems with the certificate. If this is the case,
I would expect log entries to that effect.
> To discard that my problem is for the SSL certificate, I have
> proceeded to create a local certificate and configure it in my mc
> file to compile it later.
Note: I'm successfully using a free Let's Encrypt certificate with
Sendmail.
> When sending tests, I notice in the mail header that the TLS protocol
> is visible but not verified (this is because it is a local certificate)
to the receiving system. - It's a minimal amount of work if you care.
But you are going to want a valid trusted cert when talking to servers
that you don't control.
> Received: from smtp.escondatagate.com.pe (localhost [127.0.0.1])
> by smtp.escondatagate.com.pe (8.15.1 + Sun / 8.15.1) with ESMTPS id
> x3Q5BQib021106 (version = TLSv1.2 cipher = DHE -RSA-AES256-GCM-SHA384
> bits = 256 verify = NO) for <kcar...@esconcorp.com>; Fri, 26 Apr
> 2019 00:11:26 -0500 (PET)
>
> With this I am deducting that my problem goes through an issue of the
> acquired SSL certificate and not the configuration of the sendmail,
> what do you think?
without needing to change Sendmail. Obviously you will need to restart
Sendmail to have it see and use the changed certificate.
One hack that you can do is to configure Sendmail to use certificate
file(s) that is (are) a symbolic link to the real certificate. Then you
just need to update the symbolic link and restart Sendmail when you want
to switch certificate file(s).
define(`confSERVER_CERT', `/etc/mail/server_cert.current')dnl
define(`confSERVER_KEY', `/etc/mail/server_key.current' )dnl
define(`confCLIENT_CERT', `/etc/mail/client_cert.current')dnl
define(`confCLIENT_KEY', `/etc/mail/client_key.current' )dnl
Then have files like the following:
/etc/mail/client_cert.current -> /etc/mail/client_cert.self-signed
/etc/mail/client_cert.self-signed
/etc/mail/client_cert.trusted-ca
/etc/mail/client_key.current -> /etc/mail/client_key.self-signed
/etc/mail/client_key.self-signed
/etc/mail/client_key.trusted-ca
/etc/mail/server_cert.current -> /etc/mail/server_cert.self-signed
/etc/mail/server_cert.self-signed
/etc/mail/server_cert.trusted-ca
/etc/mail/server_key.current -> /etc/mail/server_key.self-signed
/etc/mail/server_key.self-signed
/etc/mail/server_key.trusted-ca
IMHO this technique (hack) makes it easy to trade out certificates when
they need to be renewed without reconfiguring Sendmail.
1) Copy the new certificate file(s) into place.
2) Update symbolic links.
3) Restart Sendmail.
If everything works when you point to the self-signed files, but fails
with the trusted-ca files, then chances are very good that it's a
problem with the certificate files and not the Sendmail config.
> I am sending you the result of executing the openssl command (this
> test was done with the SSL certificate of SSL2BUY)
>
The fact that you're using TCP port 465 tells me that you're using the
Secure Submission port. Which means that Sendmail must be happy with
the certificate to listen.
If you were using TCP port 25 or 587, you might be able to connect but
not see STARTTLS in response to an EHLO.
I'm not sure what Sendmail's failure mode is if everything else is
happy, but has an invalid (wrong format) certificate file.
> 220 smtp.escondatagate.com.pe ESMTP Sendmail 8.15.1+Sun/8.15.1; Thu, 25 Apr 2019 23:03:04 -0500 (PET)
that TLS was negotiated properly.
0 new messages