Nick Howitt
2020-Aug-06 15:43 UTC
[Samba] Problem with intermediate certificate (tls cafile)
If I were guessing, based on some experience with certificate usage in other apps, concatenate your certificate and intermediate certificates into a single file which is then your "tls certfile" then point "tls cafile" to your issuers proper CA or just to your distro's CA bundle, e.g /etc/pki/tls/certs/ca-bundle.crt. Nick On 06/08/2020 16:36, MAS Jean-Louis via samba wrote:> Nobody has any clues about the tls cafile ? > > Regards > > Le 04/08/2020 ? 15:18, MAS Jean-Louis via samba a ?crit?: >> I have several samba servers on Debian 10 all using : >> >> samba 2:4.9.5+dfsg-5+deb10u1 amd64 >> >> I use tls cafile, tls certfile and tls keyfile with certificates from >> Sectigo (https://cert-manager.com) >> >> And when checking my connexion from the samba server, or from outside, >> I've got "unable to verify the first certificate" even if tls_cafile is >> provided in smb.conf. >> >> What is wrong ? >> >> # checking my connexion >> >> openssl s_client -showcerts -connect localhost:636 >> >> CONNECTED(00000003) >> Can't use SSL_get_servername >> depth=0 C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU >> XXX, CN = ad-rep2.example.com >> verify error:num=20:unable to get local issuer certificate >> verify return:1 >> depth=0 C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU >> XXX, CN = ad-rep2.example.com >> verify error:num=21:unable to verify the first certificate >> verify return:1 >> ... >> Server certificate >> subject=C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU =XXX, >> CN = ad-rep2.example.com >> >> issuer=C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> >> --- >> Acceptable client certificate CA names >> C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN >> = USERTrust RSA Certification Authority >> C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN >> = AAA Certificate Services >> Requested Signature Algorithms: >> RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 >> Shared Requested Signature Algorithms: >> RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 >> Peer signing digest: SHA256 >> Peer signature type: RSA-PSS >> Server Temp Key: X25519, 253 bits >> --- >> SSL handshake has read 3041 bytes and written 393 bytes >> Verification error: unable to verify the first certificate >> --- >> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >> Server public key is 2048 bit >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> No ALPN negotiated >> Early data was not sent >> Verify return code: 21 (unable to verify the first certificate) >> >> # checking my connexion with intermediate certificate >> >> openssl s_client -showcerts -connect localhost:636 -CAfile >> /etc/ssl/certs/ad-rep2.example.com-2020-intermediate.pem >> >> CONNECTED(00000003) >> Can't use SSL_get_servername >> depth=3 C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA >> Limited, CN = AAA Certificate Services >> verify return:1 >> depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST >> Network, CN = USERTrust RSA Certification Authority >> verify return:1 >> depth=1 C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> verify return:1 >> depth=0 C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU =XXX, >> CN = ad-rep2.example.com >> verify return:1 >> --- >> Certificate chain >> 0 s:C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU =XXX, CN >> = ad-rep2.example.com >> i:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> --- >> Server certificate >> subject=C = FR, postalCode = 00000, ST = XXX, L = XXX, O = XXX, OU =XXX, >> CN = ad-rep2.example.com >> >> issuer=C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> >> --- >> Acceptable client certificate CA names >> C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4 >> C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN >> = USERTrust RSA Certification Authority >> C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN >> = AAA Certificate Services >> Requested Signature Algorithms: >> RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 >> Shared Requested Signature Algorithms: >> RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 >> Peer signing digest: SHA256 >> Peer signature type: RSA-PSS >> Server Temp Key: X25519, 253 bits >> --- >> SSL handshake has read 3041 bytes and written 393 bytes >> Verification: OK >> --- >> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 >> Server public key is 2048 bit >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> No ALPN negotiated >> Early data was not sent >> Verify return code: 0 (ok) >> --- >> closed >> >> # My smb.conf >> >> [global] >> allow dns updates = nonsecure and secure >> disable spoolss = Yes >> dns forwarder = w.x.y.z a.b.c.d >> load printers = No >> log file = /var/log/samba/samba-ad.log >> netbios name = AD-REP2 >> passdb backend = samba_dsdb >> printcap cache time = 0 >> printcap name = /dev/null >> realm = EXAMPLE.COM >> server role = active directory domain controller >> server string = Samba Server Version %v >> template homedir = /home/%ACCOUNTNAME% >> template shell = /bin/bash >> tls cafile = tls/ad-rep2.example.com-2020-intermediate.pem >> tls certfile = tls/ad-rep2.example.com-2020-certonly.pem >> tls keyfile = tls/ad-rep2.example.com-2020.key >> tls verify peer = ca_and_name >> workgroup = EXAMPLE >> winbindd:use external pipes = true >> smbd:backgroundqueue = no >> rpc_daemon:spoolssd = embedded >> rpc_server:tcpip = no >> rpc_server:spoolss = embedded >> rpc_server:winreg = embedded >> rpc_server:ntsvcs = embedded >> rpc_server:eventlog = embedded >> rpc_server:srvsvc = embedded >> rpc_server:svcctl = embedded >> rpc_server:default = external >> idmap_ldb:use rfc2307 = yes >> idmap config * : backend = tdb >> lpq command = lpq -P'%p' >> lprm command = lprm -P'%p' %j >> map archive = No >> print command = lpr -r -P'%p' %s >> printing = bsd >> >> Intermediate certificates >> (tls/ad-rep2.example.com-2020-intermediate.pem) are ordered as mentioned >> in sectigo's documentation : >> >> "SSLCertificateChainFile: Intermediate(s)/Root only, PEM encoded (it >> contains the certificates from the leaf, without the certificate itself, >> to the root)" >> >> Thanks >> >
Christopher Cox
2020-Aug-06 16:15 UTC
[Samba] Problem with intermediate certificate (tls cafile)
On 8/6/20 10:43 AM, Nick Howitt via samba wrote:> If I were guessing, based on some experience with certificate usage in other > apps, concatenate your certificate and intermediate certificates into a single > file which is then your "tls certfile" then point "tls cafile" to your issuers > proper CA or just to your distro's CA bundle, e.g /etc/pki/tls/certs/ca-bundle.crt. > > Nick > > On 06/08/2020 16:36, MAS Jean-Louis via samba wrote: >> Nobody has any clues about the tls cafile ? >> >> Regards >> >> Le 04/08/2020 ? 15:18, MAS Jean-Louis via samba a ?crit?: >>> I have several samba servers on Debian 10 all using : >>> >>> samba????????? 2:4.9.5+dfsg-5+deb10u1 amd64 >>> >>> I use tls cafile, tls certfile and tls keyfile with certificates from >>> Sectigo (https://cert-manager.com) >>> >>> And when checking my connexion from the samba server, or from outside, >>> I've got "unable to verify the first certificate" even if tls_cafile is >>> provided in smb.conf. >>> >>> What is wrong ? >>> >>> # checking my connexion >>> >>> openssl s_client -showcerts -connect localhost:636Just a side note. When "checking" a certificate you need to ideally use a valid name known for the certificate. And "localhost" isn't going to be it.
MAS Jean-Louis
2020-Aug-10 07:19 UTC
[Samba] [Solved] Problem with intermediate certificate (tls cafile)
Le 06/08/2020 ? 17:43, Nick Howitt via samba a ?crit?:> If I were guessing, based on some experience with certificate usage in > other apps, concatenate your certificate and intermediate certificates > into a single file which is then your "tls certfile" then point "tls > cafile" to your issuers proper CA or just to your distro's CA bundle, > e.g /etc/pki/tls/certs/ca-bundle.crt.You're right, on Samba, it works that way # smb.conf extract tls cafile = /etc/ssl/certs/Comodo_AAA_Services_root.pem tls certfile = /etc/ssl/certs/ad-rep2.example.com-certonly+intermediate.pem tls keyfile = /etc/ssl/private/ad-rep2.example.com.key openssl s_client -showcerts -connect ad-rep2.example.com:636 .... SSL handshake has read 6020 bytes and written 428 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) Note : You're quite right Christopher about not using localhost. I retested with the FQDN but without the modifications Nick suggested above, It doesn't work either. By the way, should the Samba's documentation (https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC#Using_a_trusted_certificate) be modified to explain that particular point ? Thanks -- Jean Louis Mas
Rowland penny
2020-Aug-10 08:35 UTC
[Samba] [Solved] Problem with intermediate certificate (tls cafile)
On 10/08/2020 08:19, MAS Jean-Louis via samba wrote:> By the way, should the Samba's documentation > (https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(LDAPS)_on_a_Samba_AD_DC#Using_a_trusted_certificate) > be modified to explain that particular point ?The problem is that I run my own CA for testing purposes and with 'ldap server require strong auth = yes' effectively set in smb.conf, along with: ??????? tls keyfile? = tls/myKey.pem ??????? tls certfile = tls/myCert.pem ??????? tls cafile It works for me ;-) So the wikipage appears to be correct, as far as it goes. I will update the wikipage. Rowland
L.P.H. van Belle
2020-Aug-10 09:50 UTC
[Samba] [Solved] Problem with intermediate certificate (tls cafile)
> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Rowland penny via samba > Verzonden: maandag 10 augustus 2020 10:36 > Aan: samba at lists.samba.org > Onderwerp: Re: [Samba] [Solved] Problem with intermediate > certificate (tls cafile) > > On 10/08/2020 08:19, MAS Jean-Louis via samba wrote: > > By the way, should the Samba's documentation > > > (https://wiki.samba.org/index.php/Configuring_LDAP_over_SSL_(L > DAPS)_on_a_Samba_AD_DC#Using_a_trusted_certificate) > > be modified to explain that particular point ? > > The problem is that I run my own CA for testing purposes and > with 'ldap > server require strong auth = yes' effectively set in > smb.conf, along with: > ??????? tls keyfile? = tls/myKey.pem > ??????? tls certfile = tls/myCert.pem > ??????? tls cafile > It works for me ;-)For now, yes. But for future setups, we should use intermediate certificates now also as some browsers will mark the sites as insecure if they dont have intermediates. I'm changeing all my certificates at the moment, im adding the intermediates.> > So the wikipage appears to be correct, as far as it goes.Yes, its correct, but getting a small bit out-dated. Apple, google are making these setups more obligated. (always https and having intermediate certs). Cant find the article on the intermediates but its there somewhere. Greetz, Louis