From mhnvelu at gmail.com Tue Aug 11 19:44:50 2015 From: mhnvelu at gmail.com (Mohanavelu Subramanian) Date: Wed, 12 Aug 2015 01:14:50 +0530 Subject: [Mod_nss-list] Alternative for optional_no_ca in mod nss Message-ID: Hi All, Good Morning. I am to new mod nss mailing list. I have described the issue I am facing to support TLSv1.2 Currently, our product use Apache 2.2.12 provided by SLES 11sp3. We are doing a securing hardening now by enabling only TLSv1.2 protocol and disabling other protocols. I tried to configure "SSLProtocol TLSv1.2". But after apache restart, it throws an error "invalid protocol". I came to know that mod_ssl refers openssl 0.9.8 version, though we have latest openssl 1.0.1(which supports TLSv1.2). The mod_ssl loads openssl0.9.8 always. It seems the latest Apache version 2.4.x supports TLSv1.2. But this apache version is available in SLES 12 only which wont be available for us for another 6 months.So, we dropped this option. So, the procurement team advised us to use mod_nss which can support TLSv1.2 with Apache 2.2.12. We started the migration from mod_ssl to mod_nss and everything went well, but the directive "SSLVerifyClient optional_no_ca" is not available with mod_nss. It provides only none,optional,require.So, we are blocked on this and could not migrate to mod_nss. If I configure optional, the handshake fails. But in case of none option , I understood from the doc's available from Internet that server won't request or require client certificate. But we have clients who send their certificate and we verify those certificate for authenticity at application level instead of in apache server(no ca at apache server ). So this scenario also fails when the application looks for certificate but not sent by client because of none option . Can you please suggest how to overcome this issue, any other alternatives. Thanks in advance. Regards, Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 11 19:58:33 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Aug 2015 15:58:33 -0400 Subject: [Mod_nss-list] Alternative for optional_no_ca in mod nss In-Reply-To: References: Message-ID: <55CA53E9.6060306@redhat.com> Mohanavelu Subramanian wrote: > Hi All, > > Good Morning. > > I am to new mod nss mailing list. I have described the issue I am facing > to support TLSv1.2 > > Currently, our product use Apache 2.2.12 provided by SLES 11sp3. > We are doing a securing hardening now by enabling only TLSv1.2 protocol > and disabling other protocols. I tried to configure "SSLProtocol > TLSv1.2". But after apache restart, it throws an error "invalid > protocol". I came to know that mod_ssl refers openssl 0.9.8 version, > though we have latest openssl 1.0.1(which supports TLSv1.2). The mod_ssl > loads openssl0.9.8 always. > > It seems the latest Apache version 2.4.x supports TLSv1.2. But this > apache version is available in SLES 12 only which wont be available for > us for another 6 months.So, we dropped this option. > > So, the procurement team advised us to use mod_nss which can support > TLSv1.2 with Apache 2.2.12. We started the migration from mod_ssl to > mod_nss and everything went well, but the directive "SSLVerifyClient > optional_no_ca" is not available with mod_nss. It provides only > none,optional,require.So, we are blocked on this and could not migrate > to mod_nss. > If I configure optional, the handshake fails. > But in case of none option , I understood from the doc's available from > Internet that server won't request or require client certificate. But we > have clients who send their certificate and we verify those certificate > for authenticity at application level instead of in apache server(no ca > at apache server ). So this scenario also fails when the application > looks for certificate but not sent by client because of none option . > Can you please suggest how to overcome this issue, any other alternatives. Why can't you add the issuing CA's on the mod_nss side so optional works? optional_no_ca might be possible but it would be an ugly hack due to the way NSS callbacks work. Accepting unknown client certificates seems like a bad idea. rob From mhnvelu at gmail.com Wed Aug 12 14:50:43 2015 From: mhnvelu at gmail.com (Mohanavelu Subramanian) Date: Wed, 12 Aug 2015 20:20:43 +0530 Subject: [Mod_nss-list] Alternative for optional_no_ca in mod nss In-Reply-To: <55CA53E9.6060306@redhat.com> References: <55CA53E9.6060306@redhat.com> Message-ID: Hi Rob, Thanks a lot for your mail. I added my root certificate into mod_nss db and configured NSSVerifyClient optional. Server-Cert u,u,u server-ca C,, When I send a request to the server with client certificate, i got an exception: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: unknown_ca. Do I need to do any configuration changes in mod_nss.conf file after adding CA's certificate into mod_nss db? Please provide your inputs. Thanks & Regards, Mohan On Wed, Aug 12, 2015 at 1:28 AM, Rob Crittenden wrote: > Mohanavelu Subramanian wrote: > >> Hi All, >> >> Good Morning. >> >> I am to new mod nss mailing list. I have described the issue I am facing >> to support TLSv1.2 >> >> Currently, our product use Apache 2.2.12 provided by SLES 11sp3. >> We are doing a securing hardening now by enabling only TLSv1.2 protocol >> and disabling other protocols. I tried to configure "SSLProtocol >> TLSv1.2". But after apache restart, it throws an error "invalid >> protocol". I came to know that mod_ssl refers openssl 0.9.8 version, >> though we have latest openssl 1.0.1(which supports TLSv1.2). The mod_ssl >> loads openssl0.9.8 always. >> >> It seems the latest Apache version 2.4.x supports TLSv1.2. But this >> apache version is available in SLES 12 only which wont be available for >> us for another 6 months.So, we dropped this option. >> >> So, the procurement team advised us to use mod_nss which can support >> TLSv1.2 with Apache 2.2.12. We started the migration from mod_ssl to >> mod_nss and everything went well, but the directive "SSLVerifyClient >> optional_no_ca" is not available with mod_nss. It provides only >> none,optional,require.So, we are blocked on this and could not migrate >> to mod_nss. >> If I configure optional, the handshake fails. >> But in case of none option , I understood from the doc's available from >> Internet that server won't request or require client certificate. But we >> have clients who send their certificate and we verify those certificate >> for authenticity at application level instead of in apache server(no ca >> at apache server ). So this scenario also fails when the application >> looks for certificate but not sent by client because of none option . >> Can you please suggest how to overcome this issue, any other alternatives. >> > > Why can't you add the issuing CA's on the mod_nss side so optional works? > > optional_no_ca might be possible but it would be an ugly hack due to the > way NSS callbacks work. Accepting unknown client certificates seems like a > bad idea. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 12 17:54:06 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Aug 2015 13:54:06 -0400 Subject: [Mod_nss-list] Alternative for optional_no_ca in mod nss In-Reply-To: References: <55CA53E9.6060306@redhat.com> Message-ID: <55CB883E.8090603@redhat.com> Mohanavelu Subramanian wrote: > Hi Rob, > > Thanks a lot for your mail. > > I added my root certificate into mod_nss db and configured > NSSVerifyClient optional. > > Server-Cert u,u,u > server-ca C,, > > When I send a request to the server with client certificate, i got an > exception: > > javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: unknown_ca. > > > Do I need to do any configuration changes in mod_nss.conf file after adding CA's certificate into mod_nss db? > > Please provide your inputs. Try setting the CA trust to CT,,. The T is "trusted CA to issue client certs". This should do it: # certutil -M -d /etc/httpd/alias -n server-ca -t CT,, rob > > > Thanks & Regards, > > Mohan > > > > On Wed, Aug 12, 2015 at 1:28 AM, Rob Crittenden > wrote: > > Mohanavelu Subramanian wrote: > > Hi All, > > Good Morning. > > I am to new mod nss mailing list. I have described the issue I > am facing > to support TLSv1.2 > > Currently, our product use Apache 2.2.12 provided by SLES 11sp3. > We are doing a securing hardening now by enabling only TLSv1.2 > protocol > and disabling other protocols. I tried to configure "SSLProtocol > TLSv1.2". But after apache restart, it throws an error "invalid > protocol". I came to know that mod_ssl refers openssl 0.9.8 version, > though we have latest openssl 1.0.1(which supports TLSv1.2). The > mod_ssl > loads openssl0.9.8 always. > > It seems the latest Apache version 2.4.x supports TLSv1.2. But this > apache version is available in SLES 12 only which wont be > available for > us for another 6 months.So, we dropped this option. > > So, the procurement team advised us to use mod_nss which can support > TLSv1.2 with Apache 2.2.12. We started the migration from mod_ssl to > mod_nss and everything went well, but the directive "SSLVerifyClient > optional_no_ca" is not available with mod_nss. It provides only > none,optional,require.So, we are blocked on this and could not > migrate > to mod_nss. > If I configure optional, the handshake fails. > But in case of none option , I understood from the doc's > available from > Internet that server won't request or require client > certificate. But we > have clients who send their certificate and we verify those > certificate > for authenticity at application level instead of in apache > server(no ca > at apache server ). So this scenario also fails when the application > looks for certificate but not sent by client because of none > option . > Can you please suggest how to overcome this issue, any other > alternatives. > > > Why can't you add the issuing CA's on the mod_nss side so optional > works? > > optional_no_ca might be possible but it would be an ugly hack due to > the way NSS callbacks work. Accepting unknown client certificates > seems like a bad idea. > > rob > > From arequipeno at gmail.com Mon Aug 24 19:34:10 2015 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 24 Aug 2015 14:34:10 -0500 Subject: [Mod_nss-list] Separate NSS databases for separate vhosts Message-ID: <55DB71B2.4010302@gmail.com> Is $SUBJECT possible? I've got an existing IPA installation (IPA 3.0.0 on CentOS 6), and I'm trying to add a separate "virtual host" on a different port. The new virtual host should use a completely different server certificate (and CA chain), so I've created a separate database in a separate directory. nss.conf (set up by IPA) contains the following: NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" NSSNickname Server-Cert NSSCertificateDatabase /etc/httpd/alias The database in /etc/httpd/alias does contain the "Server-Cert" certificate: # certutil -d /etc/httpd/alias -L Certificate Nickname Trust Att SSL,S/MIM Server-Cert u,u,u ipaCert u,u,u FOO.COM IPA CA CT,C,C Signing-Cert u,u,u ZZZZ-foo.conf contains: Listen 44798 NSSPassPhraseDialog "file:/etc/httpd/foo/password.conf" NSSNickname "foo.com - StartCom Ltd." NSSCertificateDatabase /etc/httpd/foo And the database in /etc/httpd/foo does contain the "foo.com - StartCom Ltd." certificate: # certutil -d /etc/httpd/foo -L Certificate Nickname Trust Att SSL,S/MIM StartCom Class 1 Primary Intermediate Server CA - StartCom Ltd. ,, foo.com - StartCom Ltd. u,u,u StartCom Certification Authority - StartCom Ltd. ,, When I try to start Apache with this configuration, I get the following error: [error] Certificate not found: 'foo.com - StartCom Ltd.' If I change NSSNickname in ZZZZ-foo.conf to "Server-Cert", Apache starts, but the vhost on port 44798 uses the IPA certificate (from /etc/httpd/alias). So it seems pretty definitive that the NSSPassPhraseDialog and NSSCertificateDatabase options for the new vhost are both being ignored. Is this expected? And if so, is there any way to use two completely separate NSS databases for 2 different virtual hosts? Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From rcritten at redhat.com Mon Aug 24 19:46:45 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Aug 2015 15:46:45 -0400 Subject: [Mod_nss-list] Separate NSS databases for separate vhosts In-Reply-To: <55DB71B2.4010302@gmail.com> References: <55DB71B2.4010302@gmail.com> Message-ID: <55DB74A5.2070600@redhat.com> Ian Pilcher wrote: > Is $SUBJECT possible? > > I've got an existing IPA installation (IPA 3.0.0 on CentOS 6), and I'm > trying to add a separate "virtual host" on a different port. The new > virtual host should use a completely different server certificate (and > CA chain), so I've created a separate database in a separate directory. No, the NSS database is global for the httpd process. You'd need to put both server certificates into the same database. rob > > nss.conf (set up by IPA) contains the following: > > NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" > > NSSNickname Server-Cert > NSSCertificateDatabase /etc/httpd/alias > > > The database in /etc/httpd/alias does contain the "Server-Cert" > certificate: > > # certutil -d /etc/httpd/alias -L > > Certificate Nickname Trust Att > SSL,S/MIM > > Server-Cert u,u,u > ipaCert u,u,u > FOO.COM IPA CA CT,C,C > Signing-Cert u,u,u > > ZZZZ-foo.conf contains: > > Listen 44798 > > NSSPassPhraseDialog "file:/etc/httpd/foo/password.conf" > NSSNickname "foo.com - StartCom Ltd." > NSSCertificateDatabase /etc/httpd/foo > > > And the database in /etc/httpd/foo does contain the "foo.com - StartCom > Ltd." certificate: > > # certutil -d /etc/httpd/foo -L > > Certificate Nickname Trust Att > SSL,S/MIM > > StartCom Class 1 Primary Intermediate Server CA - StartCom Ltd. ,, > foo.com - StartCom Ltd. u,u,u > StartCom Certification Authority - StartCom Ltd. ,, > > When I try to start Apache with this configuration, I get the following > error: > > [error] Certificate not found: 'foo.com - StartCom Ltd.' > > If I change NSSNickname in ZZZZ-foo.conf to "Server-Cert", Apache > starts, but the vhost on port 44798 uses the IPA certificate (from > /etc/httpd/alias). > > So it seems pretty definitive that the NSSPassPhraseDialog and > NSSCertificateDatabase options for the new vhost are both being ignored. > > Is this expected? And if so, is there any way to use two completely > separate NSS databases for 2 different virtual hosts? > > Thanks! > From arequipeno at gmail.com Mon Aug 24 19:59:22 2015 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 24 Aug 2015 14:59:22 -0500 Subject: [Mod_nss-list] Separate NSS databases for separate vhosts In-Reply-To: <55DB74A5.2070600@redhat.com> References: <55DB71B2.4010302@gmail.com> <55DB74A5.2070600@redhat.com> Message-ID: <55DB779A.8020107@gmail.com> On 08/24/2015 02:46 PM, Rob Crittenden wrote: > No, the NSS database is global for the httpd process. You'd need to put > both server certificates into the same database. Bummer. I can't help thinking that the NSSCertificateDatabase (and probably NSSDBPrefix) options should be moved out of the section in nss.conf. Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From rcritten at redhat.com Mon Aug 24 20:10:47 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Aug 2015 16:10:47 -0400 Subject: [Mod_nss-list] Separate NSS databases for separate vhosts In-Reply-To: <55DB779A.8020107@gmail.com> References: <55DB71B2.4010302@gmail.com> <55DB74A5.2070600@redhat.com> <55DB779A.8020107@gmail.com> Message-ID: <55DB7A47.9020708@redhat.com> Ian Pilcher wrote: > On 08/24/2015 02:46 PM, Rob Crittenden wrote: >> No, the NSS database is global for the httpd process. You'd need to put >> both server certificates into the same database. > > Bummer. > > I can't help thinking that the NSSCertificateDatabase (and probably > NSSDBPrefix) options should be moved out of the _default_:443> section in nss.conf. > > Thanks! > Yeah, you're right. There is also a chance that NSS contexts could make this possible, but it may also add a lot of complexity. I filed https://bugzilla.redhat.com/show_bug.cgi?id=1256527 to track. rob From lcohen at novetta.com Tue Aug 25 18:03:09 2015 From: lcohen at novetta.com (Cohen, Laurence) Date: Tue, 25 Aug 2015 14:03:09 -0400 Subject: [Mod_nss-list] Very simple nss.conf file Message-ID: I would like to construct a very simple nss.conf file that will redirect all traffic to a nss.maintenance file while we are doing maintenance. I don't need help with the scripting to move the correct nss.conf into place. I just need help with the contents of the nss.conf file itself. It only needs one rule. Redirect all traffic to the maintenance file which will contain text that we are in maintenance mode. Thanks in advance. Larry C -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 25 18:21:54 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Aug 2015 14:21:54 -0400 Subject: [Mod_nss-list] Very simple nss.conf file In-Reply-To: References: Message-ID: <55DCB242.9090904@redhat.com> Cohen, Laurence wrote: > I would like to construct a very simple nss.conf file that will redirect > all traffic to a nss.maintenance file while we are doing maintenance. I > don't need help with the scripting to move the correct nss.conf into > place. I just need help with the contents of the nss.conf file itself. > It only needs one rule. Redirect all traffic to the maintenance file > which will contain text that we are in maintenance mode. For the redirect you'll need to use mod_rewrite but that's out of scope of mod_nss. This is a pretty minimal nss.conf. This page looks related: https://css-tricks.com/snippets/htaccess/temporary-maintenance-using-mod_rewrite/ Here is a pretty basic nss.conf: Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" NSSPassPhraseHelper /usr/libexec/nss_pcache NSSRequireSafeNegotiation on ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log LogLevel warn NSSEngine on NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProtocol TLSv1.0,TLSv1.1 NSSNickname Server-Cert NSSCertificateDatabase /etc/httpd/alias rob From lcohen at novetta.com Tue Aug 25 18:25:32 2015 From: lcohen at novetta.com (Cohen, Laurence) Date: Tue, 25 Aug 2015 14:25:32 -0400 Subject: [Mod_nss-list] Very simple nss.conf file In-Reply-To: <55DCB242.9090904@redhat.com> References: <55DCB242.9090904@redhat.com> Message-ID: Thanks Rob. On Tue, Aug 25, 2015 at 2:21 PM, Rob Crittenden wrote: > Cohen, Laurence wrote: > >> I would like to construct a very simple nss.conf file that will redirect >> all traffic to a nss.maintenance file while we are doing maintenance. I >> don't need help with the scripting to move the correct nss.conf into >> place. I just need help with the contents of the nss.conf file itself. >> It only needs one rule. Redirect all traffic to the maintenance file >> which will contain text that we are in maintenance mode. >> > > For the redirect you'll need to use mod_rewrite but that's out of scope of > mod_nss. This is a pretty minimal nss.conf. This page looks related: > https://css-tricks.com/snippets/htaccess/temporary-maintenance-using-mod_rewrite/ > > Here is a pretty basic nss.conf: > > Listen 443 > > AddType application/x-x509-ca-cert .crt > AddType application/x-pkcs7-crl .crl > > NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf" > NSSPassPhraseHelper /usr/libexec/nss_pcache > NSSRequireSafeNegotiation on > > > ErrorLog /etc/httpd/logs/error_log > TransferLog /etc/httpd/logs/access_log > LogLevel warn > > NSSEngine on > NSSCipherSuite > +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > NSSProtocol TLSv1.0,TLSv1.1 > NSSNickname Server-Cert > NSSCertificateDatabase /etc/httpd/alias > > > rob > -- [image: www.novetta.com] Larry Cohen System Administrator 12021 Sunset Hills Road, Suite 400 Reston, VA 20190 Email lcohen at novetta.com Office 703-885-1064 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lcohen at novetta.com Thu Aug 27 18:36:06 2015 From: lcohen at novetta.com (Cohen, Laurence) Date: Thu, 27 Aug 2015 14:36:06 -0400 Subject: [Mod_nss-list] nss.conf for doing maintenance Message-ID: Hi, I'm trying to set up an nss.conf to use while we are doing maintenance which will point all ssl traffic to a file called maintenance.html which simply states that we are doing maintenance on the server. The rewrite.conf we have set up is working fine for port 80 traffic, but the nss.conf is not working. Here are the errors I'm getting. BTW, we are using a self signed cert because this is our test system. I figured this would cause an info or at most a warning message, but not an error message. [Thu Aug 27 13:38:00 2015] [info] Connection to child 0 established (server jamie-web1:443, client "Server IP") [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 established (server jamie-web1:443, client "Server IP") [Thu Aug 27 13:38:00 2015] [info] SSL input filter read failed. [Thu Aug 27 13:38:00 2015] [error] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 closed (server jamie-web1.novetta.com:443, client Server IP) [Thu Aug 27 13:38:00 2015] [info] SSL library error -8172 writing data [Thu Aug 27 13:38:00 2015] [info] SSL Library Error: -8172 Certificate is signed by an untrusted issuer [Thu Aug 27 13:38:00 2015] [error] (20014)Internal error: proxy: pass request body failed to 10.3.238.21:443 (jamie-web1) [Thu Aug 27 13:38:00 2015] [error] proxy: pass request body failed to Server IP:443 (jamie-web1) from Server IP () [Thu Aug 27 13:38:00 2015] [info] Connection to child 1 closed (server jamie-web1:443, client "Workstation IP") This is the nss.conf I'm using. Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl NSSPassPhraseDialog file:/etc/httpd/.password.conf #NSSPassPhraseDialog builtin NSSPassPhraseHelper /usr/sbin/nss_pcache NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100 NSSSession3CacheTimeout 86400 NSSRandomSeed startup builtin DocumentRoot "/var/www/docroot" NSSProxyCheckPeerCN Off NSSEngine on NSSProxyEngine on NSSEnforceValidCerts off NSSRenegotiation on NSSRequireSafeNegotiation on NSSCipherSuite +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProxyCipherSuite +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSProtocol TLSv1 NSSNickname Server-Cert NSSCertificateDatabase /etc/httpd/alias NSSFIPS on NSSOCSP off ProxyPreserveHost On #SSLRenegBufferSize 52430000 NSSVerifyClient optional NSSOptions +ExportCertData +StdEnvVars ProxyPass https://jamie-web1/maintenance.html ProxyPassReverse https://jamie-web1/maintenance.html NSSOptions +StdEnvVars NSSOptions +StdEnvVars # initialize the SSL headers to a blank value to avoid http header forgeries RequestHeader set SSL_CLIENT_CERT "" RequestHeader set SSL_CIPHER "" RequestHeader set SSL_SESSION_ID "" RequestHeader set SSL_CIPHER_USEKEYSIZE "" RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x %{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ErrorLog /etc/httpd/logs/error_log TransferLog /etc/httpd/logs/access_log LogLevel info If anyone can help I'd appreciate it. Thanks, Larry Cohen -------------- next part -------------- An HTML attachment was scrubbed... URL: From roeften at gmail.com Sun Aug 30 20:18:19 2015 From: roeften at gmail.com (Roeften) Date: Sun, 30 Aug 2015 23:18:19 +0300 Subject: [Mod_nss-list] mod_nss certificate chain Message-ID: Hello all, I have an issue with mod_nss and replacing my old sha-1 comodo certificate with the newer sha-2 one. The new certificate came with an intermediate certificate, comodo CA certificate and a root User trust certificate. I have tried adding them one by one or all together to nss db however I still get the same problem. The problem as I see it is the Certificate chain (notice cert 2 towards the end): CONNECTED(00000003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.homersinn.net verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.homersinn.net i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA -----BEGIN CERTIFICATE----- MIIFTzCCBDegAwIBAgIQaOg9iqEcAe8uxvJL2wQaZDANBgkqhkiG9w0BAQsFADCB kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0xNTA4MjgwMDAwMDBaFw0xNzAzMjQyMzU5NTlaMFUxITAfBgNVBAsTGERv bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxGjAY BgNVBAMTEXd3dy5ob21lcnNpbm4ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3B414WQpcscGhwO0KVuWCLC0xB9Snw4/CQ3b/aAriNySh2yGl2Mn jegXlagrG4poNb46y4l2nxUHPv6SpyAFeYfo48ZgqvKrxtLrWIwU+/3uWQIcpPuv fxF56MaC1JVYFFnrCeKnSrU9Oi5QUoxcZMFkAWePhESHRXH84WiIuAkF5DY/DaiH xmynuTwey8xP180TaXoI6sSzPVVH3xJ9ov0tpDf1eO6W+W8an8RXTlzPcZvBRLCq CheqpQEVJ6DUb7u7ZpJ18Z0M/IRFpk4CsAQ09Cy43CmAcFoGPf8eYCKV/+1XPQj6 txG/r4jGimClxHD54SCbxP6vRw10y3R5GQIDAQABo4IB3TCCAdkwHwYDVR0jBBgw FoAUkK9qOpRaC9iQ6hJWc99DtDoo2ucwHQYDVR0OBBYEFAxmSrkbLi7L0DQDjTi6 kRWsLliSMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQG CCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysGAQQBsjEBAgIHMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5jb20vQ1BTMAgGBmeB DAECATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3JsMIGFBggr BgEFBQcBAQR5MHcwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t L0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTArBgNVHREEJDAighF3 d3cuaG9tZXJzaW5uLm5ldIINaG9tZXJzaW5uLm5ldDANBgkqhkiG9w0BAQsFAAOC AQEAIkx9tQNeeYpf04fWUIHgF7HbHYpBiGvxO6bd/PGIS1dG4GR/NBZOcYbRMfLf aEs2nmQi/x98l2hPwHlcRVP54cGCoJQEpwrvPaqgLabsBtWboS8Bw8MnsBX557+z gx1rElVOBSQRhYuORWuFwn4oc/jriRis45tZxvFYgvOqVdpLKBVn3CMa5D3H1bDj O+VryY/V6p/l6DVETHPXg+ij1v+42ePSZuQmYgGKigrZQun2p9QlMdKYacgZglnl afEEFNPh//IdjIkV0FIp9sxUfWbC74WMQLWmOBLfPcrQIIA9SxZ9anVI4P3FGO39 SHVDE2L18URxr9guVLqAttknbQ== -----END CERTIFICATE----- 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority -----BEGIN CERTIFICATE----- MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0 Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6 ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51 UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz 30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/ e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc 2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4 HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII 0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf +AZxAeKCINT+b72x -----END CERTIFICATE----- 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority -----BEGIN CERTIFICATE----- MIIF2DCCA8CgAwIBAgIQTKr5yttjb+Af907YWwOGnTANBgkqhkiG9w0BAQwFADCB hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTAwMTE5 MDAwMDAwWhcNMzgwMTE4MjM1OTU5WjCBhTELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCR 6FSS0gpWsawNJN3Fz0RndJkrN6N9I3AAcbxT38T6KhKPS38QVr2fcHK3YX/JSw8X pz3jsARh7v8Rl8f0hj4K+j5c+ZPmNHrZFGvnnLOFoIJ6dq9xkNfs/Q36nGz637CC 9BR++b7Epi9Pf5l/tfxnQ3K9DADWietrLNPtj5gcFKt+5eNu/Nio5JIk2kNrYrhV /erBvGy2i/MOjZrkm2xpmfh4SDBF1a3hDTxFYPwyllEnvGfDyi62a+pGx8cgoLEf Zd5ICLqkTqnyg0Y3hOvozIFIQ2dOciqbXL1MGyiKXCJ7tKuY2e7gUYPDCUZObT6Z +pUX2nwzV0E8jVHtC7ZcryxjGt9XyD+86V3Em69FmeKjWiS0uqlWPc9vqv9JWL7w qP/0uK3pN/u6uPQLOvnoQ0IeidiEyxPx2bvhiWC4jChWrBQdnArncevPDt09qZah SL0896+1DSJMwBGB7FY79tOi4lu3sgQiUpWAk2nojkxl8ZEDLXB0AuqLZxUpaVIC u9ffUGpVRr+goyhhf3DQw6KqLCGqR84onAZFdr+CGCe01a60y1Dma/RMhnEw6abf Fobg2P9A3fvQQoh/ozM6LlweQRGBY84YcWsr7KaKtzFcOmpH4MN5WdYgGq/yapiq crxXStJLnbsQ/LBMQeXtHT1eKJ2czL+zUdqnR+WEUwIDAQABo0IwQDAdBgNVHQ4E FgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB /wQFMAMBAf8wDQYJKoZIhvcNAQEMBQADggIBAArx1UaEt65Ru2yyTUEUAJNMnMvl wFTPoCWOAvn9sKIN9SCYPBMtrFaisNZ+EZLpLrqeLppysb0ZRGxhNaKatBYSaVqM 4dc+pBroLwP0rmEdEBsqpIt6xf4FpuHA1sj+nq6PK7o9mfjYcwlYRm6mnPTXJ9OV 2jeDchzTc+CiR5kDOF3VSXkAKRzH7JsgHAckaVd4sjn8OoSgtZx8jb8uk2Intzna FxiuvTwJaP+EmzzV1gsD41eeFPfR60/IvYcjt7ZJQ3mFXLrrkguhxuhoqEwWsRqZ CuhTLJK7oQkYdQxlqHvLI7cawiiFwxv/0Cti76R7CZGYZ4wUAc1oBmpjIXUDgIiK boHGhfKppC3n9KUkEEeDys30jXlYsQab5xoq2Z0B15R97QNKyvDb6KkBPvVWmcke jkk9u+UJueBPSZI9FoJAzMxZxuY67RIuaTxslbH9qh17f4a+Hg4yRvv7E491f0yL S0Zj/gA0QHDBw7mh3aZw4gSzQbzpgJHqZJx64SIDqZxubw5lT2yHh17zbqD5daWb QOhTsiedSrnAdyGN/4fy3ryM7xfft0kL0fJuMAsaDk527RH89elWsn2/x20Kk4yl 0MC2Hb46TpSi125sC8KKfPog88Tk5c0NqMuRkrF8hey1FGlmDoLnzc7ILaZRfyHB NVOFBkpdn627G190 -----END CERTIFICATE----- --- Server certificate subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.homersinn.net issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 4592 bytes and written 591 bytes This results in browser errors. When I set up mod_ssl the last certificate COMODO RSA Certification Authority has the correct issuer i.e. AddTrust External TTP Network/CN=AddTrust External CA Root. Is there a certain way to add the intermediate certificate to the database in order for mod_nss to return the complete chain or am I missing something? Here is the output using the same cert on mod_ssl: CONNECTED(00000003) depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1 depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1 depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA verify return:1 depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.homersinn.net verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.homersinn.net i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA -----BEGIN CERTIFICATE----- MIIFTzCCBDegAwIBAgIQaOg9iqEcAe8uxvJL2wQaZDANBgkqhkiG9w0BAQsFADCB kDELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0xNTA4MjgwMDAwMDBaFw0xNzAzMjQyMzU5NTlaMFUxITAfBgNVBAsTGERv bWFpbiBDb250cm9sIFZhbGlkYXRlZDEUMBIGA1UECxMLUG9zaXRpdmVTU0wxGjAY BgNVBAMTEXd3dy5ob21lcnNpbm4ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3B414WQpcscGhwO0KVuWCLC0xB9Snw4/CQ3b/aAriNySh2yGl2Mn jegXlagrG4poNb46y4l2nxUHPv6SpyAFeYfo48ZgqvKrxtLrWIwU+/3uWQIcpPuv fxF56MaC1JVYFFnrCeKnSrU9Oi5QUoxcZMFkAWePhESHRXH84WiIuAkF5DY/DaiH xmynuTwey8xP180TaXoI6sSzPVVH3xJ9ov0tpDf1eO6W+W8an8RXTlzPcZvBRLCq CheqpQEVJ6DUb7u7ZpJ18Z0M/IRFpk4CsAQ09Cy43CmAcFoGPf8eYCKV/+1XPQj6 txG/r4jGimClxHD54SCbxP6vRw10y3R5GQIDAQABo4IB3TCCAdkwHwYDVR0jBBgw FoAUkK9qOpRaC9iQ6hJWc99DtDoo2ucwHQYDVR0OBBYEFAxmSrkbLi7L0DQDjTi6 kRWsLliSMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQG CCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysGAQQBsjEBAgIHMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5jb20vQ1BTMAgGBmeB DAECATBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9D T01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3JsMIGFBggr BgEFBQcBAQR5MHcwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9jcnQuY29tb2RvY2EuY29t L0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTArBgNVHREEJDAighF3 d3cuaG9tZXJzaW5uLm5ldIINaG9tZXJzaW5uLm5ldDANBgkqhkiG9w0BAQsFAAOC AQEAIkx9tQNeeYpf04fWUIHgF7HbHYpBiGvxO6bd/PGIS1dG4GR/NBZOcYbRMfLf aEs2nmQi/x98l2hPwHlcRVP54cGCoJQEpwrvPaqgLabsBtWboS8Bw8MnsBX557+z gx1rElVOBSQRhYuORWuFwn4oc/jriRis45tZxvFYgvOqVdpLKBVn3CMa5D3H1bDj O+VryY/V6p/l6DVETHPXg+ij1v+42ePSZuQmYgGKigrZQun2p9QlMdKYacgZglnl afEEFNPh//IdjIkV0FIp9sxUfWbC74WMQLWmOBLfPcrQIIA9SxZ9anVI4P3FGO39 SHVDE2L18URxr9guVLqAttknbQ== -----END CERTIFICATE----- 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority -----BEGIN CERTIFICATE----- MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0 Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6 ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51 UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz 30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/ e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc 2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4 HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII 0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf +AZxAeKCINT+b72x -----END CERTIFICATE----- 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root -----BEGIN CERTIFICATE----- MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6 2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt 4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/ vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT 8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/ s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9 MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6 Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5 B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR pu/xO28QOG8= -----END CERTIFICATE----- 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root -----BEGIN CERTIFICATE----- MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9 uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0 WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0 Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5 6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ= -----END CERTIFICATE----- --- Server certificate subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.homersinn.net issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA --- No client certificate CA names sent Server Temp Key: ECDH, prime256v1, 256 bits --- SSL handshake has read 6093 bytes and written 375 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 2D04AB384A4034E74BAB236E9AA6AC186E1D7031CEE87B4CE3E27A4C7BA2BA97 Session-ID-ctx: Master-Key: 1DA103BFFC2AD4D5B5AD1421D607BC33C6EADE4D40E8E668F2E38D2363B2827FEEFE6F12C9EC4E9378166F45CCDE7C18 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - ec f8 b7 9d 01 b8 16 e4-22 01 ee 50 94 40 23 53 ........"..P.@ #S 0010 - 92 ec 22 d4 ac a1 1a 44-46 e6 ee ad 17 31 fd 1d .."....DF....1.. 0020 - dc cd 19 19 a8 6c 40 6e-dd d1 24 11 82 04 f4 bb .....l at n. .$..... 0030 - 31 ad bc c3 c5 aa 8c 21-0b a1 75 75 2d 70 c9 7c 1......!..uu-p.| 0040 - d4 19 c6 de 10 8f 1a af-9b 58 31 bf 07 58 6d 77 .........X1..Xmw 0050 - 36 51 fd 9b 58 fe a6 73-40 4e 2e 98 05 96 79 03 6Q..X..s at N. ...y. 0060 - 56 76 cb c0 fb da 25 15-98 fb 42 57 59 14 fb 25 Vv....%...BWY..% 0070 - 86 e7 ca 84 e4 2c 13 d8-64 ee e1 49 a9 11 d5 ff .....,..d..I.... 0080 - a5 04 d9 cf 07 c8 4c d4-5e 4b 07 6f 2f 42 91 85 ......L.^K.o/B.. 0090 - 2f a2 3c 2d 6c 15 b0 6c-7b ec c3 53 b7 14 9e 65 /.<-l..l{..S...e 00a0 - 42 d0 f9 08 8a 1d b7 43-69 e8 85 03 81 32 ec 02 B......Ci....2.. 00b0 - 03 e7 7a 5a c5 1b 64 67-52 88 46 bd cc ba 2e 39 ..zZ..dgR.F....9 Start Time: 1440965840 Timeout : 300 (sec) Verify return code: 0 (ok) Thank you, Panos -------------- next part -------------- An HTML attachment was scrubbed... URL: From stokos at suse.de Mon Aug 31 07:14:28 2015 From: stokos at suse.de (stokos at suse.de) Date: Mon, 31 Aug 2015 09:14:28 +0200 Subject: [Mod_nss-list] nss.conf for doing maintenance In-Reply-To: References: Message-ID: <20150831091428.2a1c46e8@papaya.suse.cz> On Thu, 27 Aug 2015 14:36:06 -0400 "Cohen, Laurence" wrote: Hi Laurence, > Hi, > > I'm trying to set up an nss.conf to use while we are doing maintenance > which will point all ssl traffic to a file called maintenance.html > which simply states that we are doing maintenance on the server. The > rewrite.conf we have set up is working fine for port 80 traffic, but > the nss.conf is not working. > > Here are the errors I'm getting. BTW, we are using a self signed cert > because this is our test system. I figured this would cause an info > or at most a warning message, but not an error message. > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 0 established > (server jamie-web1:443, client "Server IP") > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 established > (server jamie-web1:443, client "Server IP") > [Thu Aug 27 13:38:00 2015] [info] SSL input filter read failed. > [Thu Aug 27 13:38:00 2015] [error] SSL Library Error: -12195 Peer > does not recognize and trust the CA that issued your certificate > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 closed (server > jamie-web1.novetta.com:443, client Server IP) > [Thu Aug 27 13:38:00 2015] [info] SSL library error -8172 writing data > [Thu Aug 27 13:38:00 2015] [info] SSL Library Error: -8172 > Certificate is signed by an untrusted issuer > [Thu Aug 27 13:38:00 2015] [error] (20014)Internal error: proxy: pass > request body failed to 10.3.238.21:443 (jamie-web1) > [Thu Aug 27 13:38:00 2015] [error] proxy: pass request body failed to > Server IP:443 (jamie-web1) from Server IP () > [Thu Aug 27 13:38:00 2015] [info] Connection to child 1 closed (server > jamie-web1:443, client "Workstation IP") > I suppose that this problem is with CA certificate on remote server: You have two possible solution: 1. add CA from remote server to your certificate database at PROXY server 2. build mod_nss with a patch from this email PS: I have already worked on a similar problem for our customer. Have nice day Standa > This is the nss.conf I'm using. > > Listen 443 > > AddType application/x-x509-ca-cert .crt > AddType application/x-pkcs7-crl .crl > > NSSPassPhraseDialog file:/etc/httpd/.password.conf > #NSSPassPhraseDialog builtin > > NSSPassPhraseHelper /usr/sbin/nss_pcache > > NSSSessionCacheSize 10000 > NSSSessionCacheTimeout 100 > NSSSession3CacheTimeout 86400 > > > NSSRandomSeed startup builtin > > > > > DocumentRoot "/var/www/docroot" > NSSProxyCheckPeerCN Off > NSSEngine on > NSSProxyEngine on > NSSEnforceValidCerts off > NSSRenegotiation on > NSSRequireSafeNegotiation on > > NSSCipherSuite > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > NSSProxyCipherSuite > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > NSSProtocol TLSv1 > NSSNickname Server-Cert > NSSCertificateDatabase /etc/httpd/alias > NSSFIPS on > NSSOCSP off > > ProxyPreserveHost On > > > > #SSLRenegBufferSize 52430000 > NSSVerifyClient optional > NSSOptions +ExportCertData +StdEnvVars > ProxyPass https://jamie-web1/maintenance.html > ProxyPassReverse https://jamie-web1/maintenance.html > > > > NSSOptions +StdEnvVars > > > NSSOptions +StdEnvVars > > > > # initialize the SSL headers to a blank value to avoid http header > forgeries RequestHeader set SSL_CLIENT_CERT "" > RequestHeader set SSL_CIPHER "" > RequestHeader set SSL_SESSION_ID "" > RequestHeader set SSL_CIPHER_USEKEYSIZE "" > > RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" > RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" > RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" > RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" > > CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x > %{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" > > > ErrorLog /etc/httpd/logs/error_log > TransferLog /etc/httpd/logs/access_log > LogLevel info > > > > If anyone can help I'd appreciate it. > > Thanks, > > Larry Cohen -------------- next part -------------- A non-text attachment was scrubbed... Name: proxy-NSSProxyCheckPeerCA-off.patch Type: text/x-patch Size: 10324 bytes Desc: not available URL: From lcohen at novetta.com Mon Aug 31 14:47:52 2015 From: lcohen at novetta.com (Cohen, Laurence) Date: Mon, 31 Aug 2015 10:47:52 -0400 Subject: [Mod_nss-list] nss.conf for doing maintenance In-Reply-To: <20150831091428.2a1c46e8@papaya.suse.cz> References: <20150831091428.2a1c46e8@papaya.suse.cz> Message-ID: Thank you Standa, Option number 2 isn't possible at our site. Would you be able to explain number 1 to me? I'm very green with mod_nss so I don't know how to set this up. Thanks, Larry C. On Mon, Aug 31, 2015 at 3:14 AM, stokos at suse.de wrote: > On Thu, 27 Aug 2015 14:36:06 -0400 > "Cohen, Laurence" wrote: > > Hi Laurence, > > > Hi, > > > > I'm trying to set up an nss.conf to use while we are doing maintenance > > which will point all ssl traffic to a file called maintenance.html > > which simply states that we are doing maintenance on the server. The > > rewrite.conf we have set up is working fine for port 80 traffic, but > > the nss.conf is not working. > > > > Here are the errors I'm getting. BTW, we are using a self signed cert > > because this is our test system. I figured this would cause an info > > or at most a warning message, but not an error message. > > > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 0 established > > (server jamie-web1:443, client "Server IP") > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 established > > (server jamie-web1:443, client "Server IP") > > [Thu Aug 27 13:38:00 2015] [info] SSL input filter read failed. > > [Thu Aug 27 13:38:00 2015] [error] SSL Library Error: -12195 Peer > > does not recognize and trust the CA that issued your certificate > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 closed (server > > jamie-web1.novetta.com:443, client Server IP) > > [Thu Aug 27 13:38:00 2015] [info] SSL library error -8172 writing data > > [Thu Aug 27 13:38:00 2015] [info] SSL Library Error: -8172 > > Certificate is signed by an untrusted issuer > > [Thu Aug 27 13:38:00 2015] [error] (20014)Internal error: proxy: pass > > request body failed to 10.3.238.21:443 (jamie-web1) > > [Thu Aug 27 13:38:00 2015] [error] proxy: pass request body failed to > > Server IP:443 (jamie-web1) from Server IP () > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 1 closed (server > > jamie-web1:443, client "Workstation IP") > > > > I suppose that this problem is with CA certificate on remote server: > > You have two possible solution: > > 1. add CA from remote server to your certificate database at PROXY > server > 2. build mod_nss with a patch from this email > > > PS: I have already worked on a similar problem for our customer. > > Have nice day > > Standa > > > This is the nss.conf I'm using. > > > > Listen 443 > > > > AddType application/x-x509-ca-cert .crt > > AddType application/x-pkcs7-crl .crl > > > > NSSPassPhraseDialog file:/etc/httpd/.password.conf > > #NSSPassPhraseDialog builtin > > > > NSSPassPhraseHelper /usr/sbin/nss_pcache > > > > NSSSessionCacheSize 10000 > > NSSSessionCacheTimeout 100 > > NSSSession3CacheTimeout 86400 > > > > > > NSSRandomSeed startup builtin > > > > > > > > > > DocumentRoot "/var/www/docroot" > > NSSProxyCheckPeerCN Off > > NSSEngine on > > NSSProxyEngine on > > NSSEnforceValidCerts off > > NSSRenegotiation on > > NSSRequireSafeNegotiation on > > > > NSSCipherSuite > > > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > > > NSSProxyCipherSuite > > > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > > > NSSProtocol TLSv1 > > NSSNickname Server-Cert > > NSSCertificateDatabase /etc/httpd/alias > > NSSFIPS on > > NSSOCSP off > > > > ProxyPreserveHost On > > > > > > > > #SSLRenegBufferSize 52430000 > > NSSVerifyClient optional > > NSSOptions +ExportCertData +StdEnvVars > > ProxyPass https://jamie-web1/maintenance.html > > ProxyPassReverse https://jamie-web1/maintenance.html > > > > > > > > NSSOptions +StdEnvVars > > > > > > NSSOptions +StdEnvVars > > > > > > > > # initialize the SSL headers to a blank value to avoid http header > > forgeries RequestHeader set SSL_CLIENT_CERT "" > > RequestHeader set SSL_CIPHER "" > > RequestHeader set SSL_SESSION_ID "" > > RequestHeader set SSL_CIPHER_USEKEYSIZE "" > > > > RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" > > RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" > > RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" > > RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" > > > > CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x > > %{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" > > > > > > ErrorLog /etc/httpd/logs/error_log > > TransferLog /etc/httpd/logs/access_log > > LogLevel info > > > > > > > > If anyone can help I'd appreciate it. > > > > Thanks, > > > > Larry Cohen > > > _______________________________________________ > Mod_nss-list mailing list > Mod_nss-list at redhat.com > https://www.redhat.com/mailman/listinfo/mod_nss-list > -- [image: www.novetta.com] Larry Cohen System Administrator 12021 Sunset Hills Road, Suite 400 Reston, VA 20190 Email lcohen at novetta.com Office 703-885-1064 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 31 14:56:59 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Aug 2015 10:56:59 -0400 Subject: [Mod_nss-list] nss.conf for doing maintenance In-Reply-To: References: <20150831091428.2a1c46e8@papaya.suse.cz> Message-ID: <55E46B3B.2030304@redhat.com> Cohen, Laurence wrote: > Thank you Standa, > > Option number 2 isn't possible at our site. Would you be able to > explain number 1 to me? I'm very green with mod_nss so I don't know how > to set this up. The problem you're seeing is that in proxy mode, mod_nss is acting as a client and it doesn't trust or know the issuer of the server certificate it is contacting. So you need to get that CA cert (or chain) and add it to the mod_nss NSS database. You can add it ala: # certutil -A -d /etc/httpd/alias -n -t CT,, -a -i /path/to/ca.pem rob > > Thanks, > > Larry C. > > On Mon, Aug 31, 2015 at 3:14 AM, stokos at suse.de > > wrote: > > On Thu, 27 Aug 2015 14:36:06 -0400 > "Cohen, Laurence" > > wrote: > > Hi Laurence, > > > Hi, > > > > I'm trying to set up an nss.conf to use while we are doing > maintenance > > which will point all ssl traffic to a file called maintenance.html > > which simply states that we are doing maintenance on the server. The > > rewrite.conf we have set up is working fine for port 80 traffic, but > > the nss.conf is not working. > > > > Here are the errors I'm getting. BTW, we are using a self signed > cert > > because this is our test system. I figured this would cause an info > > or at most a warning message, but not an error message. > > > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 0 established > > (server jamie-web1:443, client "Server IP") > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 established > > (server jamie-web1:443, client "Server IP") > > [Thu Aug 27 13:38:00 2015] [info] SSL input filter read failed. > > [Thu Aug 27 13:38:00 2015] [error] SSL Library Error: -12195 Peer > > does not recognize and trust the CA that issued your certificate > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 closed > (server > > jamie-web1.novetta.com:443 , > client Server IP) > > [Thu Aug 27 13:38:00 2015] [info] SSL library error -8172 writing > data > > [Thu Aug 27 13:38:00 2015] [info] SSL Library Error: -8172 > > Certificate is signed by an untrusted issuer > > [Thu Aug 27 13:38:00 2015] [error] (20014)Internal error: proxy: pass > > request body failed to 10.3.238.21:443 > (jamie-web1) > > [Thu Aug 27 13:38:00 2015] [error] proxy: pass request body failed to > > Server IP:443 (jamie-web1) from Server IP () > > [Thu Aug 27 13:38:00 2015] [info] Connection to child 1 closed > (server > > jamie-web1:443, client "Workstation IP") > > > > I suppose that this problem is with CA certificate on remote server: > > You have two possible solution: > > 1. add CA from remote server to your certificate database at PROXY > server > 2. build mod_nss with a patch from this email > > > PS: I have already worked on a similar problem for our customer. > > Have nice day > > Standa > > > This is the nss.conf I'm using. > > > > Listen 443 > > > > AddType application/x-x509-ca-cert .crt > > AddType application/x-pkcs7-crl .crl > > > > NSSPassPhraseDialog file:/etc/httpd/.password.conf > > #NSSPassPhraseDialog builtin > > > > NSSPassPhraseHelper /usr/sbin/nss_pcache > > > > NSSSessionCacheSize 10000 > > NSSSessionCacheTimeout 100 > > NSSSession3CacheTimeout 86400 > > > > > > NSSRandomSeed startup builtin > > > > > > > > > > DocumentRoot "/var/www/docroot" > > NSSProxyCheckPeerCN Off > > NSSEngine on > > NSSProxyEngine on > > NSSEnforceValidCerts off > > NSSRenegotiation on > > NSSRequireSafeNegotiation on > > > > NSSCipherSuite > > > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > > > NSSProxyCipherSuite > > > +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > > > > NSSProtocol TLSv1 > > NSSNickname Server-Cert > > NSSCertificateDatabase /etc/httpd/alias > > NSSFIPS on > > NSSOCSP off > > > > ProxyPreserveHost On > > > > > > > > #SSLRenegBufferSize 52430000 > > NSSVerifyClient optional > > NSSOptions +ExportCertData +StdEnvVars > > ProxyPass https://jamie-web1/maintenance.html > > ProxyPassReverse https://jamie-web1/maintenance.html > > > > > > > > NSSOptions +StdEnvVars > > > > > > NSSOptions +StdEnvVars > > > > > > > > # initialize the SSL headers to a blank value to avoid http header > > forgeries RequestHeader set SSL_CLIENT_CERT "" > > RequestHeader set SSL_CIPHER "" > > RequestHeader set SSL_SESSION_ID "" > > RequestHeader set SSL_CIPHER_USEKEYSIZE "" > > > > RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" > > RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" > > RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" > > RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" > > > > CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x > > %{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" > > > > > > ErrorLog /etc/httpd/logs/error_log > > TransferLog /etc/httpd/logs/access_log > > LogLevel info > > > > > > > > If anyone can help I'd appreciate it. > > > > Thanks, > > > > Larry Cohen > > > _______________________________________________ > Mod_nss-list mailing list > Mod_nss-list at redhat.com > https://www.redhat.com/mailman/listinfo/mod_nss-list > > > > > -- > > www.novetta.com > > Larry Cohen > > System Administrator > > > 12021 Sunset Hills Road, Suite 400 > > Reston, VA 20190 > > Email lcohen at novetta.com > > Office 703-885-1064 > > > > _______________________________________________ > Mod_nss-list mailing list > Mod_nss-list at redhat.com > https://www.redhat.com/mailman/listinfo/mod_nss-list > From lcohen at novetta.com Mon Aug 31 14:59:17 2015 From: lcohen at novetta.com (Cohen, Laurence) Date: Mon, 31 Aug 2015 10:59:17 -0400 Subject: [Mod_nss-list] nss.conf for doing maintenance In-Reply-To: <55E46B3B.2030304@redhat.com> References: <20150831091428.2a1c46e8@papaya.suse.cz> <55E46B3B.2030304@redhat.com> Message-ID: Ok, I'll give this a shot. Thank you for your help. On Mon, Aug 31, 2015 at 10:56 AM, Rob Crittenden wrote: > Cohen, Laurence wrote: > >> Thank you Standa, >> >> Option number 2 isn't possible at our site. Would you be able to >> explain number 1 to me? I'm very green with mod_nss so I don't know how >> to set this up. >> > > The problem you're seeing is that in proxy mode, mod_nss is acting as a > client and it doesn't trust or know the issuer of the server certificate it > is contacting. So you need to get that CA cert (or chain) and add it to the > mod_nss NSS database. > > You can add it ala: > > # certutil -A -d /etc/httpd/alias -n -t CT,, > -a -i /path/to/ca.pem > > rob > > >> Thanks, >> >> Larry C. >> >> On Mon, Aug 31, 2015 at 3:14 AM, stokos at suse.de >> > wrote: >> >> On Thu, 27 Aug 2015 14:36:06 -0400 >> "Cohen, Laurence" > >> wrote: >> >> Hi Laurence, >> >> > Hi, >> > >> > I'm trying to set up an nss.conf to use while we are doing >> maintenance >> > which will point all ssl traffic to a file called maintenance.html >> > which simply states that we are doing maintenance on the server. >> The >> > rewrite.conf we have set up is working fine for port 80 traffic, >> but >> > the nss.conf is not working. >> > >> > Here are the errors I'm getting. BTW, we are using a self signed >> cert >> > because this is our test system. I figured this would cause an >> info >> > or at most a warning message, but not an error message. >> > >> > [Thu Aug 27 13:38:00 2015] [info] Connection to child 0 established >> > (server jamie-web1:443, client "Server IP") >> > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 established >> > (server jamie-web1:443, client "Server IP") >> > [Thu Aug 27 13:38:00 2015] [info] SSL input filter read failed. >> > [Thu Aug 27 13:38:00 2015] [error] SSL Library Error: -12195 Peer >> > does not recognize and trust the CA that issued your certificate >> > [Thu Aug 27 13:38:00 2015] [info] Connection to child 7 closed >> (server >> > jamie-web1.novetta.com:443 , >> client Server IP) >> > [Thu Aug 27 13:38:00 2015] [info] SSL library error -8172 writing >> data >> > [Thu Aug 27 13:38:00 2015] [info] SSL Library Error: -8172 >> > Certificate is signed by an untrusted issuer >> > [Thu Aug 27 13:38:00 2015] [error] (20014)Internal error: proxy: >> pass >> > request body failed to 10.3.238.21:443 >> >> (jamie-web1) >> > [Thu Aug 27 13:38:00 2015] [error] proxy: pass request body failed >> to >> > Server IP:443 (jamie-web1) from Server IP () >> > [Thu Aug 27 13:38:00 2015] [info] Connection to child 1 closed >> (server >> > jamie-web1:443, client "Workstation IP") >> > >> >> I suppose that this problem is with CA certificate on remote server: >> >> You have two possible solution: >> >> 1. add CA from remote server to your certificate database at PROXY >> server >> 2. build mod_nss with a patch from this email >> >> >> PS: I have already worked on a similar problem for our customer. >> >> Have nice day >> >> Standa >> >> > This is the nss.conf I'm using. >> > >> > Listen 443 >> > >> > AddType application/x-x509-ca-cert .crt >> > AddType application/x-pkcs7-crl .crl >> > >> > NSSPassPhraseDialog file:/etc/httpd/.password.conf >> > #NSSPassPhraseDialog builtin >> > >> > NSSPassPhraseHelper /usr/sbin/nss_pcache >> > >> > NSSSessionCacheSize 10000 >> > NSSSessionCacheTimeout 100 >> > NSSSession3CacheTimeout 86400 >> > >> > >> > NSSRandomSeed startup builtin >> > >> > >> > >> > >> > DocumentRoot "/var/www/docroot" >> > NSSProxyCheckPeerCN Off >> > NSSEngine on >> > NSSProxyEngine on >> > NSSEnforceValidCerts off >> > NSSRenegotiation on >> > NSSRequireSafeNegotiation on >> > >> > NSSCipherSuite >> > >> >> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha >> > >> > NSSProxyCipherSuite >> > >> >> +rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha >> > >> > NSSProtocol TLSv1 >> > NSSNickname Server-Cert >> > NSSCertificateDatabase /etc/httpd/alias >> > NSSFIPS on >> > NSSOCSP off >> > >> > ProxyPreserveHost On >> > >> > >> > >> > #SSLRenegBufferSize 52430000 >> > NSSVerifyClient optional >> > NSSOptions +ExportCertData +StdEnvVars >> > ProxyPass https://jamie-web1/maintenance.html >> > ProxyPassReverse https://jamie-web1/maintenance.html >> > >> > >> > >> > NSSOptions +StdEnvVars >> > >> > >> > NSSOptions +StdEnvVars >> > >> > >> > >> > # initialize the SSL headers to a blank value to avoid http header >> > forgeries RequestHeader set SSL_CLIENT_CERT "" >> > RequestHeader set SSL_CIPHER "" >> > RequestHeader set SSL_SESSION_ID "" >> > RequestHeader set SSL_CIPHER_USEKEYSIZE "" >> > >> > RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" >> > RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" >> > RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" >> > RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s" >> > >> > CustomLog /var/log/httpd/ssl_request_log "%t %h %{SSL_CLIENT_CERT}x >> > %{SSL_CLIENT_S_DN}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" >> > >> > >> > ErrorLog /etc/httpd/logs/error_log >> > TransferLog /etc/httpd/logs/access_log >> > LogLevel info >> > >> > >> > >> > If anyone can help I'd appreciate it. >> > >> > Thanks, >> > >> > Larry Cohen >> >> >> _______________________________________________ >> Mod_nss-list mailing list >> Mod_nss-list at redhat.com >> https://www.redhat.com/mailman/listinfo/mod_nss-list >> >> >> >> >> -- >> >> www.novetta.com >> >> Larry Cohen >> >> System Administrator >> >> >> 12021 Sunset Hills Road, Suite 400 >> >> Reston, VA 20190 >> >> Email lcohen at novetta.com >> >> Office 703-885-1064 >> >> >> >> _______________________________________________ >> Mod_nss-list mailing list >> Mod_nss-list at redhat.com >> https://www.redhat.com/mailman/listinfo/mod_nss-list >> >> > -- [image: www.novetta.com] Larry Cohen System Administrator 12021 Sunset Hills Road, Suite 400 Reston, VA 20190 Email lcohen at novetta.com Office 703-885-1064 -------------- next part -------------- An HTML attachment was scrubbed... URL: