Sendmail TLS config errors - what's needed?

#1

Hello

I’m running sendmail 8.15.2 on openSUSE, trying to secure it with lets encrypt signed certificates .

it isn’t working though; instead i’m getting

verify error:num=20:unable to get local issuer certificate

…when trying to establish the connection.

certificates were acquired with:

# certbot certonly --standalone --standalone --standalone-supported-challenges tls-sni-01

and the files got placed in the /etc/certbot hierachy (as expected ?)

the certificate config in sendmail.mc looks like this:

define(`SSL_DIR',		`/etc/ssl')dnl
define(`CERT_DIR',		`/etc/certbot/live/outpost.yseda.com')dnl
define(`confCACERT_PATH',	SSL_DIR`/certs')dnl
define(`confCACERT',		CERT_DIR`/fullchain.pem')dnl
define(`confSERVER_CERT',	CERT_DIR`/cert.pem')dnl
define(`confSERVER_KEY',	CERT_DIR`/privkey.pem')dnl
define(`confCLIENT_CERT',	CERT_DIR`/cert.pem')dnl
define(`confCLIENT_KEY',	CERT_DIR`/privkey.pem')dnl
define(`confCRL',SSL_DIR`/crl/cacert.org.revoke.crl')dnl

I’ve also tried using chain.pem as the confCACERT & got the same result

I have the following files in /etc/ssl/certs:

-rw-r--r-- 1 root users 1967 Sep 16 14:09 isrgrootx1.pem
-rw-r--r-- 1 root users 1675 Sep 16 14:09 lets-encrypt-x1-cross-signed.pem
-rw-r--r-- 1 root users 1675 Sep 16 14:09 lets-encrypt-x2-cross-signed.pem
-rw-r--r-- 1 root users 1647 Sep 16 14:09 lets-encrypt-x3-cross-signed.pem
-rw-r--r-- 1 root users 1647 Sep 16 14:09 lets-encrypt-x4-cross-signed.pem

the full output from openssl s_client looks like this:

CONNECTED(00000003)
depth=1 /CN=Fake LE Intermediate X1
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=outpost.yseda.com
   i:/CN=Fake LE Intermediate X1
 1 s:/CN=Fake LE Intermediate X1
   i:/CN=Fake LE Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF5zCCBM+gAwIBAgITAPqH7ztvDi0iSkVZ9agv9ok5LTANBgkqhkiG9w0BAQsF
ADAiMSAwHgYDVQQDDBdGYWtlIExFIEludGVybWVkaWF0ZSBYMTAeFw0xNjA5MTUw
NDA3MDBaFw0xNjEyMTQwNDA3MDBaMBwxGjAYBgNVBAMTEW91dHBvc3QueXNlZGEu
Y29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwwMTkduw+IUJCV57
tsEf5P4rx/LGzkhYdxb/BS40JHHgp9i3WG2MR7ZdsHE2oM0y0o+62WsEGCoqQuhx
Yd6RjTQXnr8vcIlKAd8ZgrCTZ4kbf5bvaL1lBJbmNU5Cywc/VVyDM3YHdDLHLexx
Vse4yJb73EVWRkItwUaRNwG9vkonvhqJ+bBzEh7JoOqw0jFCzKIDUjTu8vNDNiKf
B+bYYdfknZJWN2Yqe9aLcSEttlyqBd4xWG6Hs8zv/tWbl34w//Rza2eD4tYdele4
McnK4Qpf60ubi0X5DAaacm3GzWZ7yQDCRMMyW21SzhG2ITK6sd2Dd3JyPRBfPTXW
HFFGRgoxTQ/gtXtf3rjGK1vRBCCa28SYirNeWoaa6D7kwyUMq5Mkhi0szejIXmfQ
5slEUEL54sULPJHQxtAoZ6Pc7K5Yt8iZm7Mu/N6PSbqqsND97n25vT9qC+5QbLhs
PQkm3cv3eXbDRfdx+81seF/oSsWJ8aydF0A8HWkMqrVMwvdmExBpzTe6AQDfoimO
r3jZQTr82XGrvHyhGHnBhxEsaVXdLA0TWzY1fqW8MaNFcc0pMfdkbZJehmB4QKD8
usN3JpoKiDNKwuwwZZGKx6/wLZXhRDREN3J+l5yxYS+J/AXkQRscJfbBek9HaRm9
5UD57KjVriTXchZzpxLF421+bJsCAwEAAaOCAhowggIWMA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAd
BgNVHQ4EFgQUvnFpipa/QgRGulTC3fT3xiMcfJowHwYDVR0jBBgwFoAUwMwDRrlY
IMxccnDz4S7LIKb1aDoweAYIKwYBBQUHAQEEbDBqMDMGCCsGAQUFBzABhidodHRw
Oi8vb2NzcC5zdGctaW50LXgxLmxldHNlbmNyeXB0Lm9yZy8wMwYIKwYBBQUHMAKG
J2h0dHA6Ly9jZXJ0LnN0Zy1pbnQteDEubGV0c2VuY3J5cHQub3JnLzAcBgNVHREE
FTATghFvdXRwb3N0LnlzZWRhLmNvbTCB/gYDVR0gBIH2MIHzMAgGBmeBDAECATCB
5gYLKwYBBAGC3xMBAQEwgdYwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2Vu
Y3J5cHQub3JnMIGrBggrBgEFBQcCAjCBngyBm1RoaXMgQ2VydGlmaWNhdGUgbWF5
IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgUmVseWluZyBQYXJ0aWVzIGFuZCBvbmx5
IGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgQ2VydGlmaWNhdGUgUG9saWN5IGZvdW5k
IGF0IGh0dHBzOi8vbGV0c2VuY3J5cHQub3JnL3JlcG9zaXRvcnkvMA0GCSqGSIb3
DQEBCwUAA4IBAQBKaZ/+TfJqzFvVdTpp9unlNL/r25He7Z4bSXbDg3wZCMMMFnHs
YRjhC0wH7uhy5jZrod4wJwJ2/crdtrwxMQ80x2WhWVo/Lbw+Znd9jfPRCaNw2q1L
876aaXgEX5bRtEHseY+GydY/Dtv1RPFVodIPYjfQvaiU6t4tRH1kIWrfuM/c2cSW
Eskk+YcB7KQKxXhARjsjw4DSWX3H1RdD6URLm7KXNKkMkcNFUgIIWGSRzG7Y/och
MkA3VDzmtdp8HleRpaQpEyiEJkEOsGIRkH+EJVQVJ9fUmzu9i1Yv129fBRUcsrbd
W6hyfChWi5a1Gq10mE6BgYfg66BRObMQ3HOg
-----END CERTIFICATE-----
subject=/CN=outpost.yseda.com
issuer=/CN=Fake LE Intermediate X1
---
Acceptable client certificate CA names
/CN=Fake LE Intermediate X1
---
SSL handshake has read 4356 bytes and written 503 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 9B77208AEF6153295A1ED5EC98C6088C2A262621825FB400138E00849BD8DB22
    Session-ID-ctx: 
    Master-Key: D9BA7A76ADDF1A10445F790AC1B1357C07D6AE08BF63E3E8088DADC3E51C172CD99785738D8011B541C52A2C87EBA9D8
    Key-Arg   : None
    Start Time: 1474001898
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 HELP

any suggestions ?

#2

“Fake LE” is the development / testing CA operated by Let’s Encrypt for people either working on a client or on frameworks surrounding their use of Let’s Encrypt.

So that’s not a real trusted public CA. However it’s not obvious to me why your certificates were issued by this “fake” not the real thing. Did you do anything that might cause this?

#3

Thanks for the reply - that definitely helps clear up the issue & satisfies my curiosity about why it was calling itself “Fake”… this is my first LetsEncrypt certificate so I assumed that was normal.

Since there’s no openSUSE version of certbot on its homepage, I’m using the OBS version for Leap 42.1 from https://build.opensuse.org/package/show/home:ecsos:server/certbot

… turns out /etc/certbot/cli.ini has this bit in it…

# The staging/testing server
server = https://acme-staging.api.letsencrypt.org/directory
# The productive server.
# server = https://acme-v01.api.letsencrypt.org/directory

setting the correct server & re-issuing the certs fixed the problem.

thanks

#4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.