Bug 52473 - Patch to integrate apache server with OpenSSL generic PKCS#11 engine.
Summary: Patch to integrate apache server with OpenSSL generic PKCS#11 engine.
Status: RESOLVED DUPLICATE of bug 42687
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4-HEAD
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2012-01-16 16:43 UTC by Moran Jacuel
Modified: 2013-11-30 08:28 UTC (History)
1 user (show)

"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.0.x (15.63 KB, patch)
2012-01-16 16:45 UTC, Moran Jacuel
Details | Diff
Diff files from vertion 2.4.2 (16.07 KB, application/octet-stream)
2012-05-10 08:54 UTC, Moran Jacuel
"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.4.2 (16.07 KB, patch)
2012-05-10 09:09 UTC, Moran Jacuel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Moran Jacuel 2012-01-16 16:43:13 UTC
This patch integrates apache with OpenSSL generic PKCS#11 engine. 
After compiling apache with this patch you can connect to apache server with SSL using HSM that holds the Private RSA and Certificate instead of holding them in pem files. 

In order to work with this ptach you need to configure the following:
1.Edit OpenSSL.cnf (default place is /etc/ssl/openssl.cnf)

dynamic_path – the path to the generic engine_pkcs11.so
MODULE_PATH – the path to the HSM PKCS#11 so

2.Edit the apache ssl.cnf that is usually placed in $apache/mods-enabled/ssl.cnf
when $apache is the directory where apache is installed

SSLCryptoDevice pkcs11
SSLCertificateFile slot_1-id_313323334

SSLCertificateFile has the folowing format slot_num-id_name
when num is the number of the slot and name is the id in hex of the private, public and certificate objects to be used. In the above example slot_1-id_31323334 means that the ssl needs to work with slot number one and with Certificate and Private key with ID 1234, (0x31323334).

The changes we made in the mod_ssl were taken from a patch that we found in the apache bugzilla:

We found out that this patch works well with our HSM (ARX PrivateServer - http://arx.com/products/private-server-hsm). We would like to insert it in to the open source code.
Comment 1 Moran Jacuel 2012-01-16 16:45:23 UTC
Created attachment 28161 [details]
"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.0.x
Comment 2 Moran Jacuel 2012-05-10 08:54:59 UTC
Created attachment 28755 [details]
Diff files from vertion 2.4.2

We added and checked our patch on the latest version httpd-2.4.2
Comment 3 Moran Jacuel 2012-05-10 09:09:25 UTC
Created attachment 28756 [details]
"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.4.2
Comment 4 Rui Miguel Silva Seabra 2012-05-21 13:36:00 UTC
I had to slightly change the patch in order to have it applied from the root of httpd source tree, as it's commonly used in rpm specs.

As I'm having to backport Apache httpd 2.4 into a CentOS 5.x server, it's taking a bit longer than expected (a few important dependencies need to be upgraded as well), but so far it's compiling well.
Comment 5 Rui Miguel Silva Seabra 2012-05-29 17:11:50 UTC
The patch cleanly applies, and the server runs as expected with normal (aka non pkcs#11) configuration.

Since ARX integration is a mere case of configuring the OpenSSL pkcs#11 engine (in this case, engine_pkcs11 from OpenSC Project), I would very much enjoy if this patch was integrated into Apache httpd
Comment 6 Rico Huijbers 2013-05-24 08:48:22 UTC
I have some problems with this patch: Apache (2.2) hangs during startup, seemingly due to a double-locking issue. Stack trace attached below.

ENGINE_init (#23) acquires a lock, but then later in engine_table_select (#7) the thread tries to acquire the same lock again and deadlocks.

It's hard to say which piece of code is at fault here. OpenSC seems to be the most likely candidate, but then again it simply calls into libssl via a public API that has no unlocked variant, and I imagine that if the lock wasn't already held it should be acquired at that point. Anyway, tread carefully.

Software involved:

- Apache 2.2.22-6ubuntu5
- libssl 1.0.1c-4ubuntu8
- libopensc 0.13.0-0-git20121129101055
- libp11 0.2.8-2build1


#0  0xb776c424 in __kernel_vsyscall ()
#1  0xb76bb4d2 in __lll_lock_wait () from /lib/i386-linux-gnu/libpthread.so.0
#2  0xb76b6ed4 in _L_lock_776 () from /lib/i386-linux-gnu/libpthread.so.0
#3  0xb76b6d13 in pthread_mutex_lock () from /lib/i386-linux-gnu/libpthread.so.0
#4  0xb76e07d0 in apr_thread_mutex_lock () from /usr/lib/libapr-1.so.0
#5  0xb7380617 in ssl_util_thr_lock () from /usr/lib/apache2/modules/mod_ssl.so
#6  0xb718f9f5 in CRYPTO_lock (mode=mode@entry=9, type=type@entry=30, file=file@entry=0xb72a73f4 "eng_table.c", line=line@entry=258) at cryptlib.c:604
#7  0xb71fc077 in engine_table_select (table=table@entry=0xb72fe8d4 <cipher_table>, nid=nid@entry=418) at eng_table.c:258
#8  0xb71fdb55 in ENGINE_get_cipher_engine (nid=418) at tb_cipher.c:115
#9  0xb72118c2 in EVP_CipherInit_ex (ctx=ctx@entry=0xbf89b7c0, cipher=cipher@entry=0xb72ef9e0 <aes_128_ecb>, impl=impl@entry=0x0, key=key@entry=0xb6e60068 "\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\277\303)\021\307\030\303@", iv=iv@entry=0xbf89b84c "", enc=enc@entry=1) at evp_enc.c:147
#10 0xb7211a33 in EVP_EncryptInit_ex (ctx=0xbf89b7c0, cipher=0xb72ef9e0 <aes_128_ecb>, impl=0x0, key=0xb6e60068 "\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\277\303)\021\307\030\303@", iv=0xbf89b84c "") at evp_enc.c:292
#11 0xb6d63aa3 in ?? () from /usr/lib/libopensc.so.3
#12 0xb6d65aa5 in ?? () from /usr/lib/libopensc.so.3
#13 0xb6d66d05 in ?? () from /usr/lib/libopensc.so.3
#14 0xb6d670f7 in ?? () from /usr/lib/libopensc.so.3
#15 0xb6d6729f in ?? () from /usr/lib/libopensc.so.3
#16 0xb6d01c85 in sc_connect_card () from /usr/lib/libopensc.so.3
#17 0xb6fcdadd in ?? () from /usr/lib/opensc-pkcs11.so
#18 0xb6fce076 in ?? () from /usr/lib/opensc-pkcs11.so
#19 0xb6fc9521 in ?? () from /usr/lib/opensc-pkcs11.so
#20 0xb703d973 in PKCS11_CTX_load () from /usr/lib/i386-linux-gnu/libp11.so.2
#21 0xb704cdde in ?? () from /usr/lib/engines/engine_pkcs11.so
#22 0xb71fae8b in engine_unlocked_init (e=e@entry=0xb8c383f8) at eng_init.c:67
#23 0xb71fb000 in ENGINE_init (e=0xb8c383f8) at eng_init.c:130
#24 0xb736a68a in ssl_ossle_get_engine () from /usr/lib/apache2/modules/mod_ssl.so
#25 0xb736b03f in ssl_init_Engine () from /usr/lib/apache2/modules/mod_ssl.so
#26 0xb736ae1d in ssl_init_Module () from /usr/lib/apache2/modules/mod_ssl.so
#27 0xb77c51ee in ap_run_post_config (pconf=pconf@entry=0xb7492018, plog=0xb7460018, ptemp=0xb745e018, s=s@entry=0xb748c6a8) at config.c:95
#28 0xb77ae587 in main (argc=3, argv=0xbf89c464) at main.c:688
Comment 7 Rico Huijbers 2013-05-24 08:57:56 UTC
I should have mentioned in the previous comment that the engine is actually initalized *twice* by mod_ssl (once to check the configuration), and the first call works fine.

Also, the ENGINE_remove() call does not seem to have any effect: if I put in a ENGINE_by_id() call just after that, it will happily give me another instance of the pkcs11 engine, even though the comment just above says the call should fail.
Comment 8 Kaspar Brand 2013-11-30 08:17:26 UTC
Comment on attachment 28161 [details]
"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.0.x

Updating patch description and filename.
Comment 9 Kaspar Brand 2013-11-30 08:19:42 UTC
Comment on attachment 28756 [details]
"Minimal support for (openssl) engine managed keys" patch from bug 42687 adapted for 2.4.2

Updating patch description and filename.
Comment 10 Kaspar Brand 2013-11-30 08:20:52 UTC
Comment on attachment 28755 [details]
Diff files from vertion 2.4.2

Marking as absolete (superseded by attachment 28756 [details], which has the same file).
Comment 11 Kaspar Brand 2013-11-30 08:28:37 UTC
I'm resolving this as a duplicate, since bug 42687 is the place where the code was submitted by its original author. (In addition to implementation issues, I assume that licensing questions would also have to be clarified.)

For the sake of reference - the discussion stopped in June 2007 with this message, basically:


*** This bug has been marked as a duplicate of bug 42687 ***