From ramkumar.chinchani at gmail.com Tue Jul 1 05:21:38 2014 From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani) Date: Mon, 30 Jun 2014 20:21:38 -0700 Subject: [mod_gnutls-devel] populating REMOTE_USER Message-ID: Hi Marc, About mod_gnutls populating REMOTE_USER, would the following patch work for you? Thanks. diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c index d068ebb..415b3ed 100644 --- a/src/gnutls_hooks.c +++ b/src/gnutls_hooks.c @@ -1008,6 +1008,9 @@ static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, in san = "UNSUPPORTED"; } apr_table_setn(env, sanlabel, san); + if (side == 1) { + apr_table_setn(env, "REMOTE_USER", san); + } } } } @@ -1060,6 +1063,9 @@ static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t ce len = sizeof (buf); gnutls_openpgp_crt_get_name(cert, 0, buf, &len); apr_table_setn(env, MGS_SIDE("_NAME"), apr_pstrmemdup(r->pool, buf, len)); + if (side == 1) { + apr_table_setn(env, "REMOTE_USER", apr_pstrmemdup(r->pool, buf, len)); + } len = sizeof (sbuf); gnutls_openpgp_crt_get_fingerprint(cert, sbuf, &len); -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Fri Jul 4 15:48:17 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 4 Jul 2014 15:48:17 +0200 Subject: [mod_gnutls-devel] (no subject) Message-ID: Hello, The attached patch adds PKCS #11/TPM support to mod_gnutls. The objects (keys and certificates), can be specified as PKCS #11 URLs [0], and you can see those URLs using gnutls' p11tool. Most probably some better documentation of these URLs is needed. This requires gnutls 3.1.3 or later, and as a side-effect this patch allows encrypted keys to be loaded by mod_gnutls (PKCS #8/#12 and openssl format). regards, Nikos [0]. http://www.gnutls.org/manual/html_node/Reading-objects.html#Reading-objects -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-the-new-3.1.3-GnuTLS-APIs-to-obtain-private-keys.patch.gz Type: application/x-gzip Size: 12676 bytes Desc: not available URL: From calderon.thomas at gmail.com Thu Jul 10 09:09:44 2014 From: calderon.thomas at gmail.com (Thomas Calderon) Date: Thu, 10 Jul 2014 09:09:44 +0200 Subject: [mod_gnutls-devel] (no subject) In-Reply-To: References: Message-ID: Hello Nikos, I tried your patch for mod_gnutls but I am having issues to have a working setup with a PKCS#11 software token. I have investigated a bit: mod_gnutls finds my server certificate and obtains a handle on the private key stored in the PKCS#11 token. However, the TLS stack never uses them and the HTTPS service is not available. The following pattern keeps repeating in my error.log: ... [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 [...] [emerg] GnuTLS: Failed to Re-Import Private Key URL 'pkcs11:objecttype=private;object=web_server': (-300) PKCS #11 error. [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 ... Here is my Apache configuration ("web_server" being valid "label" of PKCS#11 object in my token) : ... GnuTLSEnable on GnuTLSSessionTickets on GnuTLSPriorities NORMAL GnuTLSPIN GnuTLSCertificateFile "pkcs11:objecttype=cert;object=web_server" GnuTLSKeyFile "pkcs11:objecttype=private;object=web_server" ... I think the problem might come from the code that is supposed to handle "fork" detection to re-initialize the PKCS#11 library. The PKCS#11 traces I obtained indicate multiple call in the same process to C_Initialize ending with the error code CKR_CRYPTOKI_ALREADY_INITIALIZED. Does your patch assume a specific Apache MPM model to work ? I have tried without success both the prefork and threaded Apache model. Could it be that the keying material is only initialized in Apache main process but not available in its child processes ? Thanks for your feedback. Kind regards, Thomas Calderon. On Fri, Jul 4, 2014 at 3:48 PM, Nikos Mavrogiannopoulos < n.mavrogiannopoulos at gmail.com> wrote: > Hello, > The attached patch adds PKCS #11/TPM support to mod_gnutls. The > objects (keys and certificates), can be specified as PKCS #11 URLs > [0], and you can see those URLs using gnutls' p11tool. Most probably > some better documentation of these URLs is needed. > > This requires gnutls 3.1.3 or later, and as a side-effect this patch > allows encrypted keys to be loaded by mod_gnutls (PKCS #8/#12 and > openssl format). > > regards, > Nikos > > [0]. > http://www.gnutls.org/manual/html_node/Reading-objects.html#Reading-objects > > _______________________________________________ > mod_gnutls-devel mailing list > mod_gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/mod_gnutls-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Thu Jul 10 12:54:59 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 10 Jul 2014 12:54:59 +0200 Subject: [mod_gnutls-devel] (no subject) In-Reply-To: References: Message-ID: On Thu, Jul 10, 2014 at 9:09 AM, Thomas Calderon wrote: > Hello Nikos, > I tried your patch for mod_gnutls but I am having issues to have a working > setup with a PKCS#11 software token. > I have investigated a bit: mod_gnutls finds my server certificate and > obtains a handle on the > private key stored in the PKCS#11 token. > However, the TLS stack never uses them and the HTTPS service is not > available. > > The following pattern keeps repeating in my error.log: > ... > [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 > [...] [emerg] GnuTLS: Failed to Re-Import Private Key URL > 'pkcs11:objecttype=private;object=web_server': (-300) PKCS #11 error. > [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 > I think the problem might come from the code that is supposed to handle > "fork" detection to re-initialize the PKCS#11 library. > The PKCS#11 traces I obtained indicate multiple call in the same process to > C_Initialize ending with the error code CKR_CRYPTOKI_ALREADY_INITIALIZED. Hello Thomas, It could be. After a fork() pkcs #11 requires that C_Initialize is called again, and I realized that some soft tokens return an error code in that case. Maybe we can simply ignore the already initialized error code; would ignoring it solve the issue? I'll check to it once I'm back (I'm on vacations until the 21st). > Does your patch assume a specific Apache MPM model to work ? I have tried > without success both the prefork and threaded Apache model. > Could it be that the keying material is only initialized in Apache main > process but not available in its child processes ? I have tried it on the pre-forked server, but with hardware tokens, and a modified software token that doesn't return the already initialized error. regards, Nikos From calderon.thomas at gmail.com Thu Jul 10 17:54:24 2014 From: calderon.thomas at gmail.com (Thomas Calderon) Date: Thu, 10 Jul 2014 17:54:24 +0200 Subject: [mod_gnutls-devel] (no subject) In-Reply-To: References: Message-ID: On Thu, Jul 10, 2014 at 12:54 PM, Nikos Mavrogiannopoulos < n.mavrogiannopoulos at gmail.com> wrote: > On Thu, Jul 10, 2014 at 9:09 AM, Thomas Calderon > wrote: > > Hello Nikos, > > I tried your patch for mod_gnutls but I am having issues to have a > working > > setup with a PKCS#11 software token. > > I have investigated a bit: mod_gnutls finds my server certificate and > > obtains a handle on the > > private key stored in the PKCS#11 token. > > However, the TLS stack never uses them and the HTTPS service is not > > available. > > > > The following pattern keeps repeating in my error.log: > > ... > > [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 > > [...] [emerg] GnuTLS: Failed to Re-Import Private Key URL > > 'pkcs11:objecttype=private;object=web_server': (-300) PKCS #11 error. > > [...] [emerg] GnuTLS: Failed to reinitialize PKCS #11 > > I think the problem might come from the code that is supposed to handle > > "fork" detection to re-initialize the PKCS#11 library. > > The PKCS#11 traces I obtained indicate multiple call in the same process > to > > C_Initialize ending with the error code CKR_CRYPTOKI_ALREADY_INITIALIZED. > > Hello Thomas, > It could be. After a fork() pkcs #11 requires that C_Initialize is > called again, and I realized that some soft tokens return an error > code in that case. Maybe we can simply ignore the already initialized > error code; would ignoring it solve the issue? I'll check to it once > I'm back (I'm on vacations until the 21st). > Hi Nikos, This was indeed the issue, the software token (softhsm) did not implement proper checks on fork. I managed to have a working setup using Caml Crush (our filtering PKCS#11 proxy) which is great. To go a little bit further, is it possible to fetch multiple certificates on the token to build the complete certification path ? In case it is not feasible, a workaround could consist of using local files and append them to the server certificate found on the token. Anyhow thanks for the current patch (tested on Debian 7 with gnutls backports and the patch applied over mod_gnutls version 0.6). Enjoy your holidays. Kind regards, Thomas Calderon > > > Does your patch assume a specific Apache MPM model to work ? I have tried > > without success both the prefork and threaded Apache model. > > Could it be that the keying material is only initialized in Apache main > > process but not available in its child processes ? > > I have tried it on the pre-forked server, but with hardware tokens, > and a modified software token that doesn't return the already > initialized error. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: