Extended certificate verification options and some extensions to PKCS#7 API

[Victor Wagner]

I've found that pyopenssl doesn't expose some OpenSSL functionality, vital for proper verification of certificate (chains) such as options for CRL support, policy checking etc.

Attached patch adds some new APIs

1. Several methods for X509Store object which allows to configure certificate checking options either for store created inside SSL.Context, or for independently created store (to verify PKCS7 signed messages). Also equivalents of load_verify_locations, use_default_locations etc added to X509Store object

2. Added new type of object X509Crl

3. Added set_client_cert_callback method to SSL.Context and methods for SSL.Connection to retrieve CA list and certificated type list as send by server to cleint. These functions can be called from client_cert_callback to determine which client certificate is suitable for the connection

4. Added function pkcs7_sign to create signed PKCS#7 object from data string signing it with private key and certifcate
(interface to OpenSSL PKCS7_sign function)
5. Added method verify for pkcs7 object (interface to PKCS7_verify)

6. Added methods check_privatekey and verify for X509 objects (because it is neccessary to check if privatekey matches certificate for certificates used for pkcs7 signing)

7. Added function load_private_key_from_engine for use hardware security modules, supported by OpenSSL

8. Added methods get_extension and get_extensions for X509 object (for use inside verify callbacks)
9. Some menthods of X509, X509Req, X509Name made to output correct unicode for X509 NAMEs
 This introduce backward minor incompatibility, because choosen set of flags produces output of textual representation
 slightly different from default. To make tests for dump_certificate and dump_certificate_request pass, -nameopt sep_comma_plus,utf8 added to openssl command line to generate etalon output.

[nicolas314 (nicolas314-deactivatedaccount)]

Applying your patch to a fresh pyopenssl 0.9 breaks the build:
src/crypto/crypto.h:22:21: error: x509crl.h: No such file or directory
Did you forget to include x509crl.h in your patch?

[Victor Wagner (vitus-cryptocom)]

On 2009.08.26 at 16:08:11 -0000, nicolas314 wrote:

> Applying your patch to a fresh pyopenssl 0.9 breaks the build:
> src/crypto/crypto.h:22:21: error: x509crl.h: No such file or directory
> Did you forget to include x509crl.h in your patch?

It seems, that I forget both x509crl.h and x509crl.c.

I'm attaching more correct patch here.

I've verifiet that it applies to pyOpenSSL 0.9 and builds on my system
(python 2.5).

Unfortunately, I've not yet covered added functionality by unit tests.

> --
> Extended certificate verification options and some extensions to PKCS#7 API
> https://bugs.launchpad.net/bugs/385178
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in pyOpenSSL: New
>
> Bug description:
> I've found that pyopenssl doesn't expose some OpenSSL functionality, vital for proper verification of certificate (chains) such as options for CRL support, policy checking etc.
>
> Attached patch adds some new APIs
>
> 1. Several methods for X509Store object which allows to configure certificate checking options either for store created inside SSL.Context, or for independently created store (to verify PKCS7 signed messages). Also equivalents of load_verify_locations, use_default_locations etc added to X509Store object
>
> 2. Added new type of object X509Crl
>
> 3. Added set_client_cert_callback method to SSL.Context and methods for SSL.Connection to retrieve CA list and certificated type list as send by server to cleint. These functions can be called from client_cert_callback to determine which client certificate is suitable for the connection
>
> 4. Added function pkcs7_sign to create signed PKCS#7 object from data string signing it with private key and certifcate
> (interface to OpenSSL PKCS7_sign function)
> 5. Added method verify for pkcs7 object (interface to PKCS7_verify)
>
> 6. Added methods check_privatekey and verify for X509 objects (because it is neccessary to check if privatekey matches certificate for certificates used for pkcs7 signing)
>
> 7. Added function load_private_key_from_engine for use hardware security modules, supported by OpenSSL
>
> 8. Added methods get_extension and get_extensions for X509 object (for use inside verify callbacks)
> 9. Some menthods of X509, X509Req, X509Name made to output correct unicode for X509 NAMEs
> This introduce backward minor incompatibility, because choosen set of flags produces output of textual representation
> slightly different from default. To make tests for dump_certificate and dump_certificate_request pass, -nameopt sep_comma_plus,utf8 added to openssl command line to generate etalon output.
>

[seth vidal (skvidal)]

Is there any status update on this bug?

thanks

[Victor Wagner (vitus-cryptocom)]

On 2010.06.16 at 16:05:24 -0000, seth vidal wrote:

> Is there any status update on this bug?

If you are interesting in it I can send a patch ported to recent version
of pyOpenSSL.

[Sylvain Munaut (tnt)]

How come this isn't merged ? Is there anything wrong with the patch ?

Those methods are really nice if you want to do good validation on your certificates. (and without a good validation SSL can be useless)

[Jean-Paul Calderone (exarkun)]

If you'd like to help out, updating the patch to the latest bzr trunk, pushing the result to a branch on launchpad, and creating a merge proposal would be a great way to do so. This will help me keep track of the code as well as make it easier to work with. Other things that would help are making sure the patch includes unit tests and documentation for the new APIs, as those are required for any new features or changes (I haven't looked at the patch at all, I don't know if it has these things already).

Once that's done, I'll look at it as soon as I can (and I'll remember that it's something I should do because of the merge proposal). At that point I may have feedback, such as requests for more tests or changes to the implementation. And then someone can help out again by addressing those, and so on. Then eventually I'll think that the code belongs in pyOpenSSL and merge the branch. :)