On Tue, 26 Feb 2019, LAURIA Giuseppe wrote:
I ordered a new certificate and use this new one now with the exact hostname
alias as mentioned.
No we are stuck at here ( using the new infrastructure on RHEL 7.6 and using
libreswan 3.25 ):
Feb 26 10:56:46.950060: "cloud_core_tunnel" #1: Peer ID is ID_DER_ASN1_DN: 'C=CH, O=<our-organisation>,
OU=<our-first-OU>, OU=<our-second-OU>, OU=<our-third-OU>, OU=<our-fourth-OU>, OU=<our-fifth-OU>,
CN=<server-FQD>'
Feb 26 10:56:46.950074: | checking for known CERT payloads
Feb 26 10:56:46.950080: | saving certificate of type 'X509_SIGNATURE' in 0
Feb 26 10:56:46.950084: | CERT payloads found: 1; calling pluto_process_certs()
Feb 26 10:56:46.950137: | decoded
CN=<server-FQD>,OU=<our-fifth-OU>,OU=<our-fourth-OU>,OU=<our-third-OU>,OU=<our-second-OU>,OU=<our-first-OU>,O=<our-organisation>,C=CH
Feb 26 10:56:46.950144: | cert_issuer_has_current_crl : looking for a CRL
issued by C=FR,CN=AXA-Issuing-CA-PR1,O=GIE AXA
Feb 26 10:56:46.950284: | releasing crl list in cert_issuer_has_current_crl
with result false
Feb 26 10:56:46.950292: | missing or expired CRL
Feb 26 10:56:46.953580: "cloud_core_tunnel" #1: X509: no EE-cert in chain!
The other end's CERT payload did not contain an EE certificate? Looks
like they are sending a bad certificate chain.
It looks like the Peer ID fails to decode because of missing CRL. Or because
the certificates is not allowed being a 'non-end-cert-in-chain'
It is the missing EE cert that is the real issue.
On the older server infrastructure using RHEL 6.x with
libreswan-3.15-7.5.el6_9.x86_64 we have no such problem with the same type of
certificates and CA defined within NSS database.
Installed:
libreswan.x86_64 0:3.15-7.5.el6_9
Feb 26 13:14:19: "ivr-s51_tunnel" #326: Main mode peer ID is ID_DER_ASN1_DN: '
O=<our-organisation>, OU=<our-first-OU>, CN=<server-FQD>'
Feb 26 13:14:19: | decoded
CN=<server-FQD>,OU=<our-first-OU>,O=<our-organisation>
Feb 26 13:14:19: | get_issuer_crl : looking for a CRL issued by
C=FR,CN=AXA-Issuing-CA-PR1,O=GIE AXA
Feb 26 13:14:19: | missing or expired CRL
Feb 26 13:14:19: | no end cert in chain!
Feb 26 13:14:19: | hmac prf: init 0x56294e2d15d0
Feb 26 13:14:19: | hmac prf: init symkey symkey 0x7f88c403a770 (length 32)
Feb 26 13:14:19: | hmac prf: update
Feb 26 13:14:19: | concat_symkey_bytes merge symkey(0x7f88c403a770)
bytes(0x56294c323200/32) - derive(CONCATENATE_BASE_AND_DATA)
target(SHA256_KEY_DERIVATION)
Feb 26 13:14:19: | symkey: key(0x7f88c403a770) length(32)
type/mechanism(CONCATENATE_BASE_AND_KEY 0x00000360)
Feb 26 13:14:19: | bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 26 13:14:19: | bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Feb 26 13:14:19: | concat_symkey_bytes key(0x7f88bc00e1d0) length(64)
type/mechanism(SHA256_KEY_DERIVATION 0x00000393)
Feb 26 13:14:19: | xor_symkey_chunk merge symkey(0x7f88bc00e1d0)
bytes(0x7ffc7453d1e0/64) - derive(XOR_BASE_AND_DATA)
target(CONCATENATE_BASE_AND_DATA)
Feb 26 13:14:19: | symkey: key(0x7f88bc00e1d0) length(64)
type/mechanism(SHA256_KEY_DERIVATION 0x00000393)
.
.
Feb 26 13:14:19: | required CA is 'O=GIE AXA, CN=AXA-Issuing-CA-PR1, C=FR'
Feb 26 13:14:19: | trusted_ca_nss called with a=O=GIE AXA,
CN=AXA-Issuing-CA-PR1, C=FR b=O=GIE AXA, CN=AXA-Issuing-CA-PR1, C=FR
Feb 26 13:14:19: | trusted_ca_nss returning with match
Feb 26 13:14:19: | key issuer CA is 'O=GIE AXA, CN=AXA-Issuing-CA-PR1, C=FR'
Feb 26 13:14:19: | NSS RSA verify: decrypted sig:
Feb 26 13:14:19: | fe 47 e5 4d cd e8 ff 6c a0 18 fb 75 db ad 1b 30
Feb 26 13:14:19: | be 4a a7 36 90 e4 1c 49 18 09 1d a2 bb 35 36 ee
Feb 26 13:14:19: | NSS RSA verify: hash value:
Feb 26 13:14:19: | fe 47 e5 4d cd e8 ff 6c a0 18 fb 75 db ad 1b 30
Feb 26 13:14:19: | be 4a a7 36 90 e4 1c 49 18 09 1d a2 bb 35 36 ee
Feb 26 13:14:19: | RSA Signature verified
Feb 26 13:14:19: | an RSA Sig check passed with *AwEAAaucz [preloaded key]
Note how it says [preloaded key] ?
Looks like you either hardcoded the certificate using rightcert= or you
used a rightrsasigkey= ?
Does the newer libreswan handle CA, CRL & certificates different by default ?
The newer code uses NSS instead of custom X509 validation code. NSS is
more secure, and likely more strict. Perhaps you had the cert hardcoded
and the CERT payload wasn't used before? And now we reject the hardcoded
certificate because we are more strict on the CERT payload (even if we
don't need the CERT payload due to hardcoded cert/pubkey ?)
That's a theory anyway.
Or how can the previous slacker behaviour be re installed ?
It cannot.
Or what can I do to 'avoid' checking the CRL at all and setting the certificate
as being an end-certificate ?
The other end should send its EE-cert as CERT payload. It may send
intermediate CA's as well (and we support receiving those as proper
CERT payloads or the broken microsoft pkcs#7 formatted ones).
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
