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

Bryan Harris bryanlharris at gmail.com
Tue Sep 27 12:07:49 UTC 2016


Hi Paul,

Thanks for the help.  I went ahead and tried some testing with ocsp.

I cannot seem to get the left/right VMs to contact the OCSP server,
are there any similar or known x509 bugs relating to ocsp?  I have
also gone ahead and tried the libreswan package, too.  But it has the
same results.  Nobody ever contacts the ocsp server, but if I do an
"openssl ocsp ..." command line test it works fine.

Even if I do a tcpdump on either client, I don't see any traffic going
out to 9080 or 9081 (these are the ocsp responder ports) when I am,
say, starting, stopping either ipsec or bringing up the tunnel.  Is
this the correct moment when ipsec/pluto should be checking the ocsp
server for validation of the certificates?  Or does it only check the
ocsp server during the certificate import using "ipsec import ..."
command?

Another interesting bit I noticed.  I upgraded to the libreswan repo
version of the package, however I left in-place the CRLs that I had
previously / manually imported using the crlutil command.  At that
point, if I had turned on crl check interval, pluto crashed with
messages like this.

Sep 27 07:45:48 left ipsec__plutorun: !pluto failure!:  exited with
error status 139 (signal 11)
Sep 27 07:45:48 left ipsec__plutorun: restarting IPsec after pause...

But then I had the idea that I should remove my own manually-imported
CRLs and let pluto do it.  When I did that, pluto does not crash
anymore.  However, it still only downloads the Root CA CRL and not the
Sub CA CRL.

I didn't worry about this much, since it sounds like you all are
already working on all these x509 fixes and are already aware of this.

V/r,
Bryan




On Mon, Sep 26, 2016 at 7:21 PM, Paul Wouters <paul at nohats.ca> wrote:
> On Mon, 26 Sep 2016, Bryan Harris wrote:
>
>> Hmm, for some reason I didn't notice that type of behavior.  But, we
>> are using RHEL 6 and so I wonder if version in use does not have the
>> latest features.  Or it could be that I haven't yet corrected all
>> mistakes in my commands yet, and something is causing these guys to
>> behave this way.
>>
>> Yep, after reading the man page, if crlcheckinterval is not specified
>> then RHEL version of ipsec uses zero, which means it will never fetch
>> the CRLs.
>>
>> So, I set to five seconds.  Now, when I do a full-restart and then
>> "ipse auto --up" this tunnel, whichever server is the OTHER side of
>> the tunnel successfully downloads the root CA CRL but not the Sub CA
>> CRL.  For some reason they get stuck trying to obtain the Sub CA CRL.
>> So they can get one but not the other.
>
>
> If you use the rhel6 version, then yes you will have some issues still.
> You can try to grab the rhel6 package from download.libreswan.org
> which packaes 3.18, which has some, but not all fixes, related to x509.
>>
>> mode, failing pending update
>> Sep 26 17:49:24 left pluto[2299]: |   trusted_ca_nss called with
>> a=(empty) b=(empty)
>> Sep 26 17:49:24 left pluto[2299]: "mytunnel" #1: no RSA public key
>> known for 'C=US, O=Sally, CN=right'
>> Sep 26 17:49:24 left pluto[2299]: "mytunnel" #1: sending encrypted
>> notification INVALID_KEY_INFORMATION to 192.168.122.8:500
>
>
> So one bug here is that it sends an INVALID_KEY_INFORMATION, instead
> of silently waiting for a resend of the packet (while it fetches
> the CRL meanwhile)
>
>> I see that it calls to import CRL on the first line above correctly.
>> But I never see it attempt the same function for the second CRL.
>> Instead of _import_crl it calls get_issuer_crl.  I have both Root+Sub
>> CAs + left/right cert in the NSS database on each side.  My pkcs12
>> command had an option something like -certfile <(cat sally1 sally2)
>> which imported both of them.
>
>
> Yes, we were not yet fetching all the intermediate CRLs either. That
> is being fixed now and will also be in 3.19.
>
> Paul


More information about the Swan mailing list