[Swan] INVALID_ID_INFORMATION

[LAURIA Giuseppe]

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