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

Tue Sep 27 14:04:50 UTC 2016

Here is a new, separate CRL test which I think means I need to await
the updates to the packages and use those.

When I revoked a certificate I get the following listing out of
crlutil on both sides.

[root at left:/home/blharris]
$ crlutil -L -d sql:/etc/ipsec.d -n "Sally Sub CA - Sally"
CRL Info:
:
    Version: 2 (0x1)
    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Issuer: "CN=Sally Sub CA,O=Sally,C=US"
    This Update: Tue Sep 27 13:28:57 2016
    Next Update: Thu Oct 27 13:28:57 2016
    Entry 1 (0x1):
        Serial Number:
            00:b3:78:6c:8e:3c:7a:d8:b6:ef:54:4b:70:2c:ec:19:
            f3
        Revocation Date: Tue Sep 27 13:28:44 2016
        Entry Extensions:
            Name: CRL reason code
            Data: 1 (0x1)

    CRL Extensions:
        Name: CRL Number
        Data: 4098 (0x1002)

And then when I start the tunnel I do indeed get this on the other
side from the revoked certificate.

Sep 27 10:02:28 right pluto[14581]: "mytunnel" #1: Main mode peer ID
is ID_DER_ASN1_DN: 'C=US, O=Sally, CN=left'
Sep 27 10:02:28 right pluto[14581]: | decoded CN=left,O=Sally,C=US
Sep 27 10:02:28 right pluto[14581]: | get_issuer_crl : looking for a
CRL issued by CN=Sally Sub CA,O=Sally,C=US
Sep 27 10:02:28 right pluto[14581]: | get_issuer_crl : CRL found
Sep 27 10:02:28 right pluto[14581]: | crl_strict: 1, ocsp: 0, ocsp_strict: 0
Sep 27 10:02:28 right pluto[14581]: | Certificate CN=Sally Root
CA,O=Sally,C=US failed verification : Peer's Certificate has been
revoked.
Sep 27 10:02:28 right pluto[14581]: "mytunnel" #1: certificate revoked!
Sep 27 10:02:28 right pluto[14581]: "mytunnel" #1: Peer public key is
not available for this exchange
Sep 27 10:02:28 right pluto[14581]: "mytunnel" #1: sending encrypted
notification INVALID_ID_INFORMATION to 192.168.122.7:500

V/r,
Bryan

On Tue, Sep 27, 2016 at 8:07 AM, Bryan Harris <bryanlharris at gmail.com> wrote:
> 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