[Swan] INVALID_ID_INFORMATION

[LAURIA Giuseppe]

Hi Paul.

Thank you very much.

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

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.


Thank you very much.

Best regards.
Giuseppe


-----Ursprüngliche Nachricht-----
Von: Paul Wouters <paul at nohats.ca> 
Gesendet: Donnerstag, 31. Januar 2019 19:21
An: LAURIA Giuseppe <giuseppe.lauria at axa-winterthur.ch>
Cc: swan at lists.libreswan.org
Betreff: [EXTERNAL] Re: [Swan] INVALID_ID_INFORMATION

On Thu, 31 Jan 2019, LAURIA Giuseppe wrote:

> We are using libreswan between two different RedHat Servers and want to do host-to-host transport tunnel encryption to port 8080.

> Left: RHEL 7.6 ( SELinux set to Permissive ) libreswan version: 
> libreswan-3.25-2.el7.x86_64

> Right: RHEL 6.10
> 
> Libreswan version : libreswan-3.15-7.5.el6_9.x86_64

> I have to say that the left certificate has a CN which contains an 
> left-server-alias for Loadbalancer, which is not yet in place. But the certificate has also a SAN list which contains the correct hostname.
> 
> But if libreswan ignores SAN and checks for the exact entry in the first DN than this will fail.
> Can you say whether libreswan checks also for the SAN entries ?

libreswan does check SAN entries, but 3.15 is very old and does not have all the flexibility of recent libreswan's with respect to certificates.

> Jan 31 18:31:13: "cloud_core_tunnel" #681: Main mode peer ID is ID_DER_ASN1_DN: '<CN-of-LB-Alias-which-does-not-yet-exist>'

I would recommend using the full DN for the leftid/rightid to avoid the subjectAltNames altogether.

Paul