Bug 1679394

Summary:	libreswan using NSS IPsec profiles regresses when critical flags are set causing validation failure
Product:	Red Hat Enterprise Linux 8	Reporter:	Paul Wouters <pwouters>
Component:	libreswan	Assignee:	Paul Wouters <pwouters>
Status:	CLOSED ERRATA	QA Contact:	Jaroslav Aster <jaster>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	jaster, wchadwic
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1679735 (view as bug list)		Environment:
Last Closed:	2019-11-05 20:59:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1679735

Description Paul Wouters 2019-02-21 04:33:14 UTC

Description of problem:
NSS IPsec profile uses an interpretation of RFC 4945 that causes regression for those CA deployments that set the critical flags on key usage payloads.

Using the TLS profile of NSS, which was in use before using the NSS IPsec profile, does not reject based on critical flags.


Proposed fix:
Verify certificates using the IPsec profile first, if that fails, try using the TLS profile. (The TLS profile method tries as TLS server, then as TLS client).

By chaining the new method with the old method, we ensure there is no regression for those using the old method and those needing the new method.

Comment 1 Paul Wouters 2019-02-21 04:42:28 UTC

See related rhbz#1643388

Comment 4 Paul Wouters 2019-02-21 05:05:46 UTC

Proposed patch from upstream: https://github.com/libreswan/libreswan/commit/7de7d5cdb6717101b8161891ed4344dfd32f5e4c

This was tested against upstream test case https://github.com/libreswan/libreswan/tree/master/testing/pluto/ikev2-x509-02-eku to show no regression on EKU.

Comment 6 Paul Wouters 2019-02-21 15:24:01 UTC

note the certificates with the bogus critical flag were created by tinyca. Apparently when you change any setting and save it, it sets the critical flag. So when you go to set server certificate settings and save them, client certificate settings switch to critical, despite not touching client certificate settings at all.

This also probably means it is fairly uncommon as tinyca is not widely used.

Comment 12 errata-xmlrpc 2019-11-05 20:59:01 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3391