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' <[email protected]>
Cc: [email protected]
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 <[email protected]>
Gesendet: Freitag, 1. Februar 2019 15:41
An: LAURIA Giuseppe <[email protected]>
Cc: [email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
