[Swan] Question/troubleshooting x509 w/ intermediate & root CA
bryanlharris at gmail.com
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"
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):
Revocation Date: Tue Sep 27 13:28:44 2016
Name: CRL reason code
Data: 1 (0x1)
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: "mytunnel" #1: Main mode peer ID
is ID_DER_ASN1_DN: 'C=US, O=Sally, CN=left'
Sep 27 10:02:28 right pluto: | decoded CN=left,O=Sally,C=US
Sep 27 10:02:28 right pluto: | get_issuer_crl : looking for a
CRL issued by CN=Sally Sub CA,O=Sally,C=US
Sep 27 10:02:28 right pluto: | get_issuer_crl : CRL found
Sep 27 10:02:28 right pluto: | crl_strict: 1, ocsp: 0, ocsp_strict: 0
Sep 27 10:02:28 right pluto: | Certificate CN=Sally Root
CA,O=Sally,C=US failed verification : Peer's Certificate has been
Sep 27 10:02:28 right pluto: "mytunnel" #1: certificate revoked!
Sep 27 10:02:28 right pluto: "mytunnel" #1: Peer public key is
not available for this exchange
Sep 27 10:02:28 right pluto: "mytunnel" #1: sending encrypted
notification INVALID_ID_INFORMATION to 192.168.122.7:500
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 ..."
> 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.
> 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: | trusted_ca_nss called with
>>> a=(empty) b=(empty)
>>> Sep 26 17:49:24 left pluto: "mytunnel" #1: no RSA public key
>>> known for 'C=US, O=Sally, CN=right'
>>> Sep 26 17:49:24 left pluto: "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.
More information about the Swan