<div dir="ltr"><div><div>Tobias,<br><br></div>Perfect, great explanation. The "rightca=@#<hex SHAH hash>" worked great for me.<br><br>Thank you,<br></div>~Mark<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, May 5, 2014 at 6:53 AM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Mark,<br>
<br>
> 17:03:45 06[CFG] CA certificate *"C=US, O=Entrust, Inc.,<br>
<div class="">> OU=<a href="http://www.entrust.net/rpa" target="_blank">www.entrust.net/rpa</a> is incorporated by<br>
> reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority<br>
</div>> - L1C" not found, discarding CA constraint*<br>
<br>
That's due to a limitation of the DN string parser:  It can't handle<br>
comma's in RDNs (which are already separated with commas).<br>
<br>
According to RFC 4514 [1] commas could be escaped with backslashes in<br>
string representations (e.g. "O=Entrust\, Inc.") but strongSwan<br>
currently doesn't support such escape sequences either.<br>
<br>
And because the parser supports an alternative encoding that uses<br>
slashes to separate RDNs (e.g. "/C=US/O=Entrust, Inc./OU=..."), but<br>
currently handles commas and slashes interchangeably, the slash in the<br>
URL in the first OU RDN triggers the same issue.<br>
<br>
We could easily change the parser so it uses either commas or slashes<br>
(if the string starts with a slash) as separator in one DN.  But this<br>
would only help if you could get rid of either the slash or the commas.<br>
 Otherwise, a bigger change in the parser would be required (e.g. adding<br>
support for escape sequences).<br>
<br>
Fortunately there is a simple workaround for this.  You can use key IDs<br>
instead of DNs to identify the CA.  Something like rightca=@#<hex> where<br>
<hex> is the hex encoded SHA1 hash of either subjectPublicKey or<br>
subjectPublicKeyInfo of your CA certificate.  You can determine those<br>
with pki --print.  The hash over the subjectPublicKey is also encoded in<br>
certificates issued by the pki utility, as subjectKeyIdentifier<br>
extension, and also as authorityKeyIdentifier extension in end-entity<br>
certificates issued by a CA.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="http://tools.ietf.org/html/rfc4514#section-3" target="_blank">http://tools.ietf.org/html/rfc4514#section-3</a><br>
<br>
</blockquote></div><br></div>