Re: Feature Request: Optional No Cert validation on SSL connector
Yep, this is a problem. And, as I said, we don't have keystores, so even if it did pick up the new cert it still wouldn't work for us. jean-frederic clere wrote: OK I have added a new CA using: +++ [EMAIL PROTECTED]:~> $JAVA_HOME/bin/keytool -import -trustcacerts -file ~/CERTS/demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts +++ To get Tomcat accepting client certificates from this CA I had to restart it... Bad. -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: jean-frederic clere wrote: Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? That's the problem, Tomcat might not know the CA that signed the cert. All certificate information, including CA(s), are expressed in the SAML2 metadata file. It could be that the CA that signed the client cert was something like Verisign, but it's much more likely to be the case that it's some organization's CA, which Tomcat wouldn't know about. OK I have added a new CA using: +++ [EMAIL PROTECTED]:~> $JAVA_HOME/bin/keytool -import -trustcacerts -file ~/CERTS/demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts +++ To get Tomcat accepting client certificates from this CA I had to restart it... Bad. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
jean-frederic clere wrote: > Chad La Joie wrote: > >> Yeah, I know what mod-ssl says, and for most cases it's probably right, >> however the optional_no_ca option is interesting to us because it >> provides exactly the functionality that we need; accepting the client >> cert, putting it in a standard place, and allowing our application to do >> the verification for us. >> >> As you said, PKCS12 wouldn't help us. The problem isn't that the Java >> keystore is some how flawed. It's that that's just not a viable >> mechanism for us. Our certificates are communicated in SAML2 metadata >> files. These files change periodically (when new service or identity >> providers come online or old ones go offline). We had discussed a >> process whereby we'd extract the certs from the file and create a >> keystore but that has and unacceptable drawback, in our opinion. With >> the SAML2 metadata files we can get fresh copies of those files and use >> them immediately in a running system. With the keystore mechanism >> Tomcat would need to be restarted because the keystore, or at least part >> of it, is cached in memory and as far as I can tell, the cache is never >> refreshed. Given the indeterminate frequency for metadata updates, we >> do not see this as a viable solution for a production level system. > > > I am not sure I got it right... > > If you have clients that use client certificates you only need to get > them signed by a CA that is known by Tomcat or do you want to change the > server certificate Tomcat is using? That's the problem, Tomcat might not know the CA that signed the cert. All certificate information, including CA(s), are expressed in the SAML2 metadata file. It could be that the CA that signed the client cert was something like Verisign, but it's much more likely to be the case that it's some organization's CA, which Tomcat wouldn't know about. -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? jean-frederic clere wrote: Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= "PKCS12" doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. jean-frederic clere wrote: > Chad La Joie wrote: > >> Hey guys, >> I was wondering if there were any thoughts on this particular >> suggestion. I hadn't seen anything on the list. > > > BTW: mod-ssl says: > +++ > In practice only levels none and require are really interesting, because > level optional doesn't work with all browsers and level optional_no_ca > is actually against the idea of authentication (but can be used to > establish SSL test pages, etc.) > +++ > > And keystoreType= "PKCS12" doesn't help. > >> >> Chad La Joie wrote: >> >>> Good Morning, >>> I work on the Internet2 Shibboleth project and we've run in to an >>> issue with client cert authentication in a stand alone Tomcat >>> environment (i.e. without Apache HTTPD in front of it). Shibboleth >>> clients use client cert auth when talking with the Shibboleth server, >>> however, the certificate chains for the clients are not in a Java >>> keystore. Instead they are in XML files that contain a large amount of >>> metadata needed by both the client and the server. >>> Our current, supported, deployment configuration is to have Apache >>> HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" >>> HTTPD directive. This allows the client to send its certificate, but >>> instead of HTTPD trying to validate the cert, it just passes the cert on >>> to the Shibboleth server. This allows us to validate the certificate >>> against the cert chains in the metadata files within the server code (a >>> huge support boon for us). What we'd like to request is a similar >>> option for the SSL connector when client cert auth is used so that we >>> can support a stand alone Tomcat set up too. >>> Would this be possible? >> >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= "PKCS12" doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. Have you tried to use keystoreType="PKCS12" in the connector? Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
{TOML#001-926-078}Feature Request: Optional No Cert validation on SSL connector
Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. Assuring you of our best services always. Warm Regards, Customer Relations TimesofMoney.com A Times Group Company - This is an automated response. Please do not respond to this email. -
{TOML#001-926-076}Feature Request: Optional No Cert validation on SSL connector
Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. Assuring you of our best services always. Warm Regards, Customer Relations TimesofMoney.com A Times Group Company - This is an automated response. Please do not respond to this email. -
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. Chad La Joie wrote: > Good Morning, > I work on the Internet2 Shibboleth project and we've run in to an > issue with client cert authentication in a stand alone Tomcat > environment (i.e. without Apache HTTPD in front of it). Shibboleth > clients use client cert auth when talking with the Shibboleth server, > however, the certificate chains for the clients are not in a Java > keystore. Instead they are in XML files that contain a large amount of > metadata needed by both the client and the server. > Our current, supported, deployment configuration is to have Apache > HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" > HTTPD directive. This allows the client to send its certificate, but > instead of HTTPD trying to validate the cert, it just passes the cert on > to the Shibboleth server. This allows us to validate the certificate > against the cert chains in the metadata files within the server code (a > huge support boon for us). What we'd like to request is a similar > option for the SSL connector when client cert auth is used so that we > can support a stand alone Tomcat set up too. > Would this be possible? -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Feature Request: Optional No Cert validation on SSL connector
Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use "SSLVerifyClient optional_no_ca" HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
