[Swan] INVALID_ID_INFORMATION

Tue Feb 26 12:49:42 UTC 2019

Hi Paul.

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!
Feb 26 10:56:46.953603: "cloud_core_tunnel" #1: X509: Certificate rejected for this connection
Feb 26 10:56:46.953612: "cloud_core_tunnel" #1: X509: CERT payload bogus or revoked
Feb 26 10:56:46.953619: | Peer ID failed to decode
Feb 26 10:56:46.953624: | complete v1 state transition with INVALID_ID_INFORMATION

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' 

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]
Feb 26 13:14:19: | authentication succeeded
Feb 26 13:14:19: | complete v1 state transition with STF_OK
Feb 26 13:14:19: "ivr-s51_tunnel" #326: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Feb 26 13:14:19: | parent state #326: STATE_MAIN_I3(open-ike) > STATE_MAIN_I4(established-authenticated-ike)
Feb 26 13:14:19: | ignore states: 0
Feb 26 13:14:19: | half-open-ike states: 0
Feb 26 13:14:19: | open-ike states: 1
Feb 26 13:14:19: | established-anonymous-ike states: 0
Feb 26 13:14:19: | established-authenticated-ike states: 1
Feb 26 13:14:19: | anonymous-ipsec states: 0
Feb 26 13:14:19: | authenticated-ipsec states: 0
Feb 26 13:14:19: | informational states: 0
Feb 26 13:14:19: | unknown states: 0
Feb 26 13:14:19: | category states: 2 count states: 2
Feb 26 13:14:19: | state: #326 requesting EVENT_v1_RETRANSMIT to be deleted
Feb 26 13:14:19: | event_schedule_ms called for about 2647000 ms
Feb 26 13:14:19: | event_schedule_tv called for about 2647 seconds and change
Feb 26 13:14:19: | inserting event EVENT_SA_REPLACE, timeout in 2647.000000 seconds for #326
Feb 26 13:14:19: "ivr-s51_tunnel" #326: STATE_MAIN_I4: ISAKMP SA established {auth=RSA_SIG cipher=aes_256 integ=OAKLEY_SHA2_256 group=MODP2048}

Does the newer libreswan handle CA, CRL & certificates different by default ?

Or how can the previous slacker behaviour be re installed ?

Or what can I do to 'avoid' checking the CRL at all and setting the certificate as being an end-certificate ?

Thank you very much for your support.
Best regards.

Giuseppe Lauria

-----Ursprüngliche Nachricht-----
Von: LAURIA Giuseppe 
Gesendet: Montag, 4. Februar 2019 10:00
An: 'Paul Wouters' <paul at nohats.ca>
Cc: swan at lists.libreswan.org
Betreff: Re: [Swan] INVALID_ID_INFORMATION

Hi Paul.
Thank you very much.

>> As long as the IKE ID you are using is either the RDN or one of the subjectAltNames, you should be fine.

As I understand an RDN is one of the components of a DN ( RDN= relative distinguished names  ). And could be different things, so which one are you referring ?
Did you maybe mean CN ( CommonName )? ( eg "CN=<server-fqdn>" ) ?

Thank you.
Giuseppe

-----Ursprüngliche Nachricht-----
Von: Paul Wouters <paul at nohats.ca>
Gesendet: Freitag, 1. Februar 2019 15:41
An: LAURIA Giuseppe <giuseppe.lauria at axa-winterthur.ch>
Cc: swan at lists.libreswan.org
Betreff: [EXTERNAL] Re: [Swan] INVALID_ID_INFORMATION

On Fri, 1 Feb 2019, LAURIA Giuseppe wrote:

> Now the problem is I re used the server certificate of this application to use it also as ipsec certificate.

In general that works, although we are seeing an issue with the new NSS IPsec certificate validation support (you can disable this using a compile time option NSS_HAS_IPSEC_PROFILE)

> So either I should order the DNS-Alias to match the <CN-of-LB-Alias-which-does-not-yet-exist>.
> Or I should order new certificates . I think I order the new certificates.
>
> What is best practice , to have just the 'ipsec' own certificate ? And not to reuse application ( server ) certificates ?
>
> And would you use the dns-alias or the hostname of the box ? The 
> dns-alias is somewhat 'readable', whereas the hostname is cryptic in 
> our company. ( Eg Alias = 'cherryCloudProd1.<domain>' vs hostname = 
> 'fhcs201a.<domain>' )
>
> We would prefer to use the Alias, but if best practice is hostname I think I would order the new certificate containing the hostname.

As long as the IKE ID you are using is either the RDN or one of the subjectAltNames, you should be fine.

Paul