[Swan] INVALID_ID_INFORMATION

Tue Feb 26 15:11:43 UTC 2019

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