support for CRLs

[seppovic]

Hey,

I was wondering how to include crlDistributionPoints in Certificates created with easy-rsa and still keep it as simple as possible with intermediate CAs in mind. I'm not sure if this is the right way to ask for help but i came up this idea. What do you think / How would you implement it?

I am new to github so i hope this is an appropriate way to get in touch.
Thx in advance
seppovic

[QueuingKoala]

The easy-rsa 3.x series (tracked on the -master branch) is a complete re-write and already includes support for CDP and easy expansion for any other common extensions (such as AIA and the like.) I'd encourage you to take a look at the features there and see if that meets your needs; 3.x is quite a bit more flexible in these regards. The doc/EasyRSA-Advanced documentation has a section on extension handling with CDP specifically in mind.

I don't really think this belongs on the 2.x release & maintenance branch, at least not as it stands now. There are a number of problems I see with this currently:

1. $TMP_CRL should probably be quoted on lines 173/174 to avoid globbing/splitting
2. echo -n isn't POSIX. printf is preferred instead, although not currently used in the 2.x code anywhere
3. perl isn't a POSIX-provided external and adds another program dependency. awk or sed are preferred as POSIX utilities.
4. Use of --inter adjusts the config file, which also adds CDP extensions to the [server] section, then doesn't remove them; future invocations to sign server-certs will unintentionally add the CDP in
5. Short of hand-editing the cnf, there's no way to control CDP usage for the server type certs, and support doesn't exist at all for the client type
6. The vars change doesn't match the existing style, and should indicate that this is a CDP as it incorrectly states it is including the CRL in the cert. This also shouldn't be enabled by default.
7. CDP doesn't make sense in a root CA cert, only certs issued by that CA.

All in all, I really encourage you to use the 3.x release instead of trying to get this support working for 2.x. The design in the new codebase is much more suited to this kind of thing, and what you want is probably as simple as uncommenting the existing example line within x509-types/COMMON.

[seppovic]

Hey Josh,
thanks for your quick reply.
I will definitely look into the 3.x branch, but i was using easy-rsa(2) for years and was always wondering why it was not possible to include a cdp uri. These days the first certificates expired and i had the time looking into easy-rsa and openssl, study openssl.conf syntax etc.

My Changes are definitely not meant to be state of the art. My intention was to "discuss the lack of this feature" and ask you how one could implement this, i didn't know about the 3.x branch as i started hacking on it and i was not sure how to get in touch with you.
I am also not sure if i understand the use cdp extension correctly.
My assumption was that i would add a cdp for all server certs signed by my ca. Sub CAs would include their own cdp and sign server certs including the their cdp. is this correct? or would i also include cdps in usercerts?

kind regards.

[QueuingKoala]

The CDP extension can be used by any application configured to process it (people can also manually use them to help verify revocation status.)

A CDP is added by an issuer to the certs it signs that indicates where that issuing CA publishes the CRL for downstream consumption.

If you have a chain that looks like ..

RootCA -> SubCA -> Entity

.. then CDP usage might look like:

• RootCA: no CDP. A CA doesn't generally "revoke itself", so a CDP on the root is mostly meaningless.
• SubCA: The CDP points to where the RootCA CRL is stored, such as http://example.net/RootCA-crl.pem
• Entity: The CDP points to where the SubCA CRL is stored, such as http://example.net/SubCA-crl.pem

If an application wants to know if the SubCA is valid, it processes the RootCA's CRL since that is its issuer. Likewise, to know if the Entity cert is valid, the SubCA's CRL is checked.

If you have further questions about usage or operation, it might be a good idea to post to the openvpn-users list. That list has more viewership and questions asked there are search-engine-indexed.

[seppovic]

Hey Josh,
thanks again for your help. You made this a lot more clearer to me.
I will now go and have a look into 3.x
What is the best way to get in touch if i need help? is there a forum or irc channel?

[ecrist]

#openvpn on freenode, or #openvpn-devel, for now. May need an easy-rsa channel at some point.

---

Eric F Crist

On Dec 19, 2013, at 13:42:20, seppovic notifications@github.com wrote:

Hey Josh,
thanks again for your help. You made this a lot more clearer to me.
I will now go and have a look into 3.x
What is the best way to get in touch if i need help? is there a forum or irc channel?

—
Reply to this email directly or view it on GitHub.

[seppovic]

Ok. Thanks eric