Hi Paul, 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:
[name_constraints] permitted;DNS.0=example.com permitted;DNS.1=example.org excluded;IP.0=0.0.0.0/0.0.0.0 excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 I thought, perhaps this is causing the message about "The Certifying Authority for this certificate is not permitted to issue a certificate with this name." So I just commented those lines like so: [name_constraints] # permitted;DNS.0=example.com # permitted;DNS.1=example.org excluded;IP.0=0.0.0.0/0.0.0.0 excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 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: Sep 26 10:24:01 right pluto[4250]: | Certificate CN=Sub CA,O=Example,C=GB failed verification : security library: invalid arguments. Sep 26 10:24:01 right pluto[4250]: | trusted_ca_nss called with a=(empty) b=(empty) Sep 26 10:24:01 right pluto[4250]: "mytunnel" #1: no RSA public key known for 'C=GB, O=Example, CN=left' Sep 26 10:24:01 right pluto[4250]: "mytunnel" #1: sending encrypted notification INVALID_KEY_INFORMATION to 192.168.122.7:500 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. V/r, Bryan On Mon, Sep 26, 2016 at 7:22 AM, Bryan Harris <[email protected]> wrote: > Hi Paul, > > 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. > > 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. > > 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. > > Sep 23 13:30:08 right pluto[16936]: | get_issuer_crl : looking for a CRL > issued by CN=Sub CA,O=Example,C=GB > Sep 23 13:30:08 right pluto[16936]: | missing or expired CRL > Sep 23 13:30:08 right pluto[16936]: | crl_strict: 0, ocsp: 0, ocsp_strict: > 0 > 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. > Sep 23 13:30:08 right pluto[16936]: | trusted_ca_nss called with > a=(empty) b=(empty) > Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: EXPECTATION FAILED at > /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev1.c:2843: r != > NULL > Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: no suitable connection > for peer 'C=GB, O=Example, CN=left' > Sep 23 13:30:08 right pluto[16936]: "mytunnel" #2: sending encrypted > notification INVALID_ID_INFORMATION to 192.168.122.7:500 > > V/r, > Bryan > > On Mon, Sep 26, 2016 at 12:33 AM, Paul Wouters <[email protected]> wrote: > >> On Fri, 23 Sep 2016, Bryan Harris wrote: >> >> Welp, I got to playing around with the old certs that were working, and I >>> somehow broke them. Then I went back >>> through everything and noticed I had to change the trust bits. >>> >>> So these trust bits work: >>> >>> "CT,," >>> >> >> Yes, you need the trust bits set properly. Libreswan does that on >> startup using the "ipsec checknss" command (as part of the service >> startup). Older versions did not do this. >> >> >> And I can't recall where I found the documentation for these, but I had >>> read it at some point. But the NEW certs >>> import properly in the first place, so there is not a need (I thought) >>> to set any trust bits (the new ones look like >>> "CT,," so I left it alone). >>> >> >> The "ipsec import" should also properly set the trust bits. >> >> One other funny thing is that even though the tunnel works using the old >>> certs with the proper trust bits, when I do >>> a "ipsec auto --listall" each server still only shows its own cert in >>> that top list for "List of RSA Public Keys". >>> >> >> The remote endpoint certificate will come in over IKE, so you will only >> see that once you received it from the other end. >> >> Paul >> > >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
