[Swan] Question/troubleshooting x509 w/ intermediate & root CA
bryanlharris at gmail.com
Mon Sep 26 18:46:25 UTC 2016
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: | get_issuer_crl : looking for a CRL
issued by CN=Sally Sub CA,O=Sally,C=US
Sep 26 14:07:34 right pluto: | missing or expired CRL
Sep 26 14:07:34 right pluto: | crl_strict: 0, ocsp: 0, ocsp_strict: 0
Sep 26 14:07:34 right pluto: | 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
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.
On Mon, Sep 26, 2016 at 10:35 AM, Bryan Harris <bryanlharris at gmail.com>
> 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:
> 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:
> # permitted;DNS.0=example.com
> # permitted;DNS.1=example.org
> 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: | Certificate CN=Sub CA,O=Example,C=GB
> failed verification : security library: invalid arguments.
> Sep 26 10:24:01 right pluto: | trusted_ca_nss called with
> a=(empty) b=(empty)
> Sep 26 10:24:01 right pluto: "mytunnel" #1: no RSA public key known
> for 'C=GB, O=Example, CN=left'
> Sep 26 10:24:01 right pluto: "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.
> On Mon, Sep 26, 2016 at 7:22 AM, Bryan Harris <bryanlharris at gmail.com>
>> 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: | get_issuer_crl : looking for a CRL
>> issued by CN=Sub CA,O=Example,C=GB
>> Sep 23 13:30:08 right pluto: | missing or expired CRL
>> Sep 23 13:30:08 right pluto: | crl_strict: 0, ocsp: 0,
>> ocsp_strict: 0
>> Sep 23 13:30:08 right pluto: | 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: | trusted_ca_nss called with
>> a=(empty) b=(empty)
>> Sep 23 13:30:08 right pluto: "mytunnel" #2: EXPECTATION FAILED at
>> /builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev1.c:2843: r !=
>> Sep 23 13:30:08 right pluto: "mytunnel" #2: no suitable connection
>> for peer 'C=GB, O=Example, CN=left'
>> Sep 23 13:30:08 right pluto: "mytunnel" #2: sending encrypted
>> notification INVALID_ID_INFORMATION to 192.168.122.7:500
>> 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:
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Swan