<div dir="ltr"><div>Hi Paul,<br><br>I have continued to go through, one thing I tried to fix (but I'm not sure if correctly) was what appears to be a name constraints issue.  I noticed in the example configuration they have the root CA and the sub CA name constraints like this:<br><br>[name_constraints]<br>permitted;DNS.0=<a href="http://example.com">example.com</a><br>permitted;DNS.1=<a href="http://example.org">example.org</a><br>excluded;IP.0=<a href="http://0.0.0.0/0.0.0.0">0.0.0.0/0.0.0.0</a><br>excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0<br><br></div>I thought, perhaps this is causing the message about <span class="gmail-im">"The Certifying Authority for this certificate is 
not permitted to issue a certificate with this name."  So I just commented those lines like so:<br></span><div><br>[name_constraints]<br># permitted;DNS.0=<a href="http://example.com">example.com</a><br># permitted;DNS.1=<a href="http://example.org">example.org</a><br>excluded;IP.0=<a href="http://0.0.0.0/0.0.0.0">0.0.0.0/0.0.0.0</a><br>excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0<br><br></div><div>Now I have regenerated the Sub CA from the Root CA, then regenerated the right and left certificates.  I thought perhaps now I would not get the message.  But now I'm getting a message like so:<br><br>Sep 26 10:24:01 right pluto[4250]: | Certificate CN=Sub CA,O=Example,C=GB failed verification : security library: invalid arguments.<br>Sep 26 10:24:01 right pluto[4250]: |   trusted_ca_nss called with a=(empty) b=(empty)<br>Sep 26 10:24:01 right pluto[4250]: "mytunnel" #1: no RSA public key known for 'C=GB, O=Example, CN=left'<br>Sep 26 10:24:01 right pluto[4250]: "mytunnel" #1: sending encrypted notification INVALID_KEY_INFORMATION to <a href="http://192.168.122.7:500">192.168.122.7:500</a><br><br></div><div>Is it possible that I need to regenerate the root CA as well as the Sub CA and the left/right certificates?  The root CA does not even have the name constraints in it, so I thought it would be unnecessary.  But I wonder if I just need to start over.<br><br></div><div>V/r,<br></div><div>Bryan<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 7:22 AM, Bryan Harris <span dir="ltr"><<a href="mailto:bryanlharris@gmail.com" target="_blank">bryanlharris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Paul,<br><br></div>Any idea why the remote endpoint certificate is not able to come over IKE?  Here are the most relevant-looking lines from the logs, but I do not understand.  Is it possible that since I have specified the CRL that is needed to be available?  I thought without strictcrlpolicy (which I do not set) then it would be okay.<br><br></div>But I can't figure out where it's going wrong or why.  I do not ever seem to get the remote certificate pulled in from either side.<br><br></div><div>I also notice it says "The Certifying Authority for this certificate is 
not permitted to issue a certificate with this name."  Why does it think my CA is not permitted to issue a certificate for its own name, or for itself?  I'm a little confused on that one, and I wonder if that may be the reason the thing doesn't work.<br></div><span class=""><div><br>Sep 23 13:30:08 right pluto[16936]: | get_issuer_crl : looking for a CRL issued by CN=Sub CA,O=Example,C=GB<br>Sep 23 13:30:08 right pluto[16936]: | missing or expired CRL<br>Sep 23 13:30:08 right pluto[16936]: | crl_strict: 0, ocsp: 0, ocsp_strict: 0<br>Sep
 23 13:30:08 right pluto[16936]: | Certificate CN=Root CA,O=Example,C=GB
 failed verification : The Certifying Authority for this certificate is 
not permitted to issue a certificate with this name.<br>Sep 23 13:30:08 right pluto[16936]: |   trusted_ca_nss called with a=(empty) b=(empty)<br>Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: EXPECTATION FAILED at /builddir/build/BUILD/libreswa<wbr>n-3.15/programs/pluto/ikev1.c:<wbr>2843: r != NULL<br>Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: no suitable connection for peer 'C=GB, O=Example, CN=left'<br>Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: sending encrypted notification INVALID_ID_INFORMATION to <a href="http://192.168.122.7:500" target="_blank">192.168.122.7:500</a><br><br></div></span>V/r,<br></div>Bryan<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 12:33 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 23 Sep 2016, Bryan Harris wrote:<br>
<br>
</span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Welp, I got to playing around with the old certs that were working, and I somehow broke them.  Then I went back<br>
through everything and noticed I had to change the trust bits.<br>
<br>
So these trust bits work:<br>
<br>
"CT,,"<br>
</blockquote>
<br></span>
Yes, you need the trust bits set properly. Libreswan does that on<br>
startup using the "ipsec checknss" command (as part of the service<br>
startup). Older versions did not do this.<span><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And I can't recall where I found the documentation for these, but I had read it at some point.  But the NEW certs<br>
import properly in the first place, so there is not a need (I thought) to set any trust bits (the new ones look like<br>
"CT,," so I left it alone).<br>
</blockquote>
<br></span>
The "ipsec import" should also properly set the trust bits.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One other funny thing is that even though the tunnel works using the old certs with the proper trust bits, when I do<br>
a "ipsec auto --listall" each server still only shows its own cert in that top list for "List of RSA Public Keys". <br>
</blockquote>
<br></span>
The remote endpoint certificate will come in over IKE, so you will only<br>
see that once you received it from the other end.<span><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>