So, with all the hubbub around POODLE and ssl, we're preparing a new load balancer using HAProxy.
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit "host: foo.com" http header but that fails for SSL certificate validation.
You can also set a hosts file entry, but that's also rather painful. Is there a better option?
On 10/21/2014 04:57 PM, lists@benjamindsmith.com wrote:
So, with all the hubbub around POODLE and ssl, we're preparing a new load balancer using HAProxy.
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit "host: foo.com" http header but that fails for SSL certificate validation.
You can also set a hosts file entry, but that's also rather painful. Is there a better option? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I just disabled SSLv3 altogether on my server and just use TLS. On my site I only use TLS 1.2 and not earlier versions or SSL so I was never affected by POODLE.
On Tuesday, October 21, 2014 05:02:53 PM Travis Kendrick wrote:
On 10/21/2014 04:57 PM, lists@benjamindsmith.com wrote:
So, with all the hubbub around POODLE and ssl, we're preparing a new load balancer using HAProxy.
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit "host: foo.com" http header but that fails for SSL certificate validation.
You can also set a hosts file entry, but that's also rather painful. Is there a better option? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I just disabled SSLv3 altogether on my server and just use TLS. On my site I only use TLS 1.2 and not earlier versions or SSL so I was never affected by POODLE.
As far as I can tell, this comment is not related to the question I asked... at all.
On 10/21/2014 06:24 PM, lists@benjamindsmith.com wrote:
On Tuesday, October 21, 2014 05:02:53 PM Travis Kendrick wrote:
On 10/21/2014 04:57 PM, lists@benjamindsmith.com wrote:
So, with all the hubbub around POODLE and ssl, we're preparing a new load balancer using HAProxy.
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit "host: foo.com" http header but that fails for SSL certificate validation.
You can also set a hosts file entry, but that's also rather painful. Is there a better option? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I just disabled SSLv3 altogether on my server and just use TLS. On my site I only use TLS 1.2 and not earlier versions or SSL so I was never affected by POODLE.
As far as I can tell, this comment is not related to the question I asked... at all. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I thought you were talking about dealing with POODLE. Maybe I misunderstood.
On 10/21/2014 06:24 PM, lists@benjamindsmith.com wrote:
On Tuesday, October 21, 2014 05:02:53 PM Travis Kendrick wrote:
On 10/21/2014 04:57 PM, lists@benjamindsmith.com wrote:
So, with all the hubbub around POODLE and ssl, we're preparing a new load balancer using HAProxy.
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit "host: foo.com" http header but that fails for SSL certificate validation.
You can also set a hosts file entry, but that's also rather painful. Is there a better option? _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I just disabled SSLv3 altogether on my server and just use TLS. On my site I only use TLS 1.2 and not earlier versions or SSL so I was never affected by POODLE.
As far as I can tell, this comment is not related to the question I asked... at all. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Maybe I did misunderstood, in which case ignore my post and/or remove it as it didn't help.
On Tue, Oct 21, 2014 at 02:57:42PM -0700, lists@benjamindsmith.com wrote:
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
openssl s_client -connect ip.ad.dr.ess:443 then decode the cert
e.g. $ openssl s_client -connect 1.2.3.4:443 < /dev/null >| cert
Now you can use the "x509" to look at various things eg $ openssl x509 -in cert -subject -noout subject= /description=foobar/C=US/CN=ssl.example.com/emailAddress=foo@example.com
"man x509"
On Tuesday, October 21, 2014 06:07:29 PM Stephen Harris wrote:
On Tue, Oct 21, 2014 at 02:57:42PM -0700, lists@benjamindsmith.com wrote:
So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype "foo.com" server if it's not actually active at the IP address that matches DNS for foo.com?
openssl s_client -connect ip.ad.dr.ess:443 then decode the cert
e.g. $ openssl s_client -connect 1.2.3.4:443 < /dev/null >| cert
Now you can use the "x509" to look at various things eg $ openssl x509 -in cert -subject -noout subject= /description=foobar/C=US/CN=ssl.example.com/emailAddress=foo@example.com
"man x509"
The issue is that I wouldn't consider myself qualified to make sense of this output. Curl noticed when an intermediate SSL cert wasn't installed correctly, so if possible I'd really like to use a CLI "browser" such as curl or wget. I've already confirmed for example, that using openssl s_client as you mention above doesn't actually check the certs, just lists them.
Thus, the recent issues with firefox and intermediate certs would be tough to look for....
On Tue, Oct 21, 2014 at 04:17:25PM -0700, lists@benjamindsmith.com wrote:
I've already confirmed for example, that using openssl s_client as you mention above doesn't actually check the certs, just lists them.
Actually it does check them as well.
e.g. openssl s_client -connect localhost:443 < /dev/null > /dev/null depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com verify error:num=10:certificate has expired notAfter=Aug 9 23:55:39 2014 GMT verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com notAfter=Aug 9 23:55:39 2014 GMT verify return:1 DONE
Notice the "verify error" lines; it's both self-signed _and_ expired.
In chained certs it'll check each of the chains.
e.g. openssl s_client -connect www.google.com:443 < /dev/null > /dev/null CONNECTED(00000003) depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2 verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
You can do a _LOT_ with the openssl command line (e.g. show all the intermediate certs in detail with -showcerts). 'man s_client'
If you have a server with a broken intermediate chain then run the command and see what it returns.
On Tuesday, October 21, 2014 07:28:13 PM Stephen Harris wrote:
On Tue, Oct 21, 2014 at 04:17:25PM -0700, lists@benjamindsmith.com wrote:
I've already confirmed for example, that using openssl s_client as you mention above doesn't actually check the certs, just lists them.
Actually it does check them as well.
e.g. openssl s_client -connect localhost:443 < /dev/null > /dev/null depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com verify error:num=10:certificate has expired notAfter=Aug 9 23:55:39 2014 GMT verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com notAfter=Aug 9 23:55:39 2014 GMT verify return:1 DONE
Notice the "verify error" lines; it's both self-signed _and_ expired.
In chained certs it'll check each of the chains.
e.g. openssl s_client -connect www.google.com:443 < /dev/null > /dev/null CONNECTED(00000003) depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2 verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify return:1
Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
You can do a _LOT_ with the openssl command line (e.g. show all the intermediate certs in detail with -showcerts). 'man s_client'
If you have a server with a broken intermediate chain then run the command and see what it returns.
I ended up discovering that curl recently added the option --resolve that allows me to do what I need. I had to download a statically compiled version and install in /usr/local to get it working on EL6.
Am 22.10.2014 um 20:14 schrieb Benjamin Smith lists@benjamindsmith.com:
On Tuesday, October 21, 2014 07:28:13 PM Stephen Harris wrote:
On Tue, Oct 21, 2014 at 04:17:25PM -0700, lists@benjamindsmith.com wrote:
I've already confirmed for example, that using openssl s_client as you mention above doesn't actually check the certs, just lists them.
Actually it does check them as well.
e.g. openssl s_client -connect localhost:443 < /dev/null > /dev/null depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com verify error:num=10:certificate has expired notAfter=Aug 9 23:55:39 2014 GMT verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/ CN=a.example.com/emailAddress=root@a.example.com notAfter=Aug 9 23:55:39 2014 GMT verify return:1 DONE
Notice the "verify error" lines; it's both self-signed _and_ expired.
In chained certs it'll check each of the chains.
e.g. openssl s_client -connect www.google.com:443 < /dev/null > /dev/null CONNECTED(00000003) depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority verify return:1 depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify return:1 depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2 verify return:1 depth=0 /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com verify return:1
Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
You can do a _LOT_ with the openssl command line (e.g. show all the intermediate certs in detail with -showcerts). 'man s_client'
If you have a server with a broken intermediate chain then run the command and see what it returns.
I ended up discovering that curl recently added the option --resolve that allows me to do what I need. I had to download a statically compiled version and install in /usr/local to get it working on EL6.
just add your host into /etc/hosts
-- LF
-
Benjamin Smith -
Leon Fauster -
lists＠benjamindsmith.com
-
Stephen Harris -
Travis Kendrick