[Swan] Question/troubleshooting x509 w/ intermediate & root CA

[Bryan Harris]

After starting from scratch the tunnel comes up.  The major differences are
the lack of nameconstraints and I published the CA certs and the CRLs where
they are specified in the x509v3 extension that shows the URL for each.  I
also used different names (US instead of GB and so forth) but I thought it
hardly should matter.

I then checked with firefox that I could get to both the root/sub
certificates as well as the root/sub CRLs, and it worked.  The funny thing
is, pluto still cannot (seemingly) get to them.  At least, that's what it
appears to complain about.  But if I check from command line using wget or
curl, I can get to them fine.

Sep 26 14:07:34 right pluto[7928]: | get_issuer_crl : looking for a CRL
issued by CN=Sally Sub CA,O=Sally,C=US
Sep 26 14:07:34 right pluto[7928]: | missing or expired CRL
Sep 26 14:07:34 right pluto[7928]: | crl_strict: 0, ocsp: 0, ocsp_strict: 0
Sep 26 14:07:34 right pluto[7928]: | certificate is valid

But in any case, the certificate comes up valid this time, whereas last
time it gave an error message.

I have to assume that all my troubles had to do mainly with the naming
constraints.

After trying to use strictcrlpolicy=yes, it didn't work.  Then I recalled a
mailing list message about having to manually import the CRL and so I did
that (using der format and command found on the wiki), now the tunnel works
with CRLs and strict crl policy in the configuration file.

V/r,
Bryan

On Mon, Sep 26, 2016 at 10:35 AM, Bryan Harris <bryanlharris at gmail.com>
wrote:

> 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 <bryanlharris at gmail.com>
> 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 <paul at nohats.ca> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20160926/9ad095d8/attachment-0001.html>