cURL PHP SSL - Unable to verify server side, but not always -
i ran troubles using mandrill php api
ssl certificate problem: unable local issuer certificate
i have dig informations on net configuring cacarts file curl. have current cert extract http://curl.haxx.se/docs/caextract.html, , configured (valid) path file in php.ini
curl.cainfo=some\local\path\\certs\cacert.pem
now testing multiple https websites (src of test here)
$this->nxs_curltest("https://mandrillapp.com/api/1.0/users/ping.json", "testapicall", "mandrill api cert"); $this->nxs_curltest("https://www.google.com/intl/en/contact/", "https google", "mountain view, ca"); $this->nxs_curltest("http://www.google.com/intl/en/contact/", "http google", "mountain view, ca"); $this->nxs_curltest("https://www.facebook.com/", "https facebook", 'id="facebook"'); $this->nxs_curltest("https://www.linkedin.com/", "https linkedin", 'link rel="canonical" href="https://www.linkedin.com/"'); $this->nxs_curltest("https://twitter.com/", "https twitter", 'link rel="canonical" href="https://twitter.com/"'); $this->nxs_curltest("https://www.pinterest.com/", "https pinterest", 'content="pinterest"'); $this->nxs_curltest("https://www.tumblr.com/", "https tumblr", 'content="tumblr"');
and got inconsistent results like:
testing ... https://mandrillapp.com/api/1.0/users/ping.json - https://mandrillapp.com/api/1.0/users/ping.json ....testapicall - problem ssl certificate problem: unable local issuer certificate array ( [url] => https://mandrillapp.com/api/1.0/users/ping.json [content_type] => [http_code] => 0 [header_size] => 0 [request_size] => 0 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 0.14 [namelookup_time] => 0 [connect_time] => 0.062 [pretransfer_time] => 0 [size_upload] => 0 [size_download] => 0 [speed_download] => 0 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => -1 [starttransfer_time] => 0 [redirect_time] => 0 [certinfo] => array ( ) [primary_ip] => 54.195.231.78 [primary_port] => 443 [local_ip] => 192.168.2.142 [local_port] => 63719 [redirect_url] => ) there problem curl. need contact server admin or hosting provider.testing ... https://www.google.com/intl/en/contact/ - https://www.google.com/intl/en/contact/ ....https google - ok testing ... http://www.google.com/intl/en/contact/ - http://www.google.com/intl/en/contact/ ....http google - ok testing ... https://www.facebook.com/ - https://www.facebook.com/ ....https facebook - ok testing ... https://www.linkedin.com/ - https://www.linkedin.com/ ....https linkedin - ok testing ... https://twitter.com/ - https://twitter.com/ ....https twitter - ok testing ... https://www.pinterest.com/ - https://www.pinterest.com/ ....https pinterest - problem ssl certificate problem: unable local issuer certificate array ( [url] => https://www.pinterest.com/ [content_type] => [http_code] => 0 [header_size] => 0 [request_size] => 0 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 0.078 [namelookup_time] => 0 [connect_time] => 0.016 [pretransfer_time] => 0 [size_upload] => 0 [size_download] => 0 [speed_download] => 0 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => -1 [starttransfer_time] => 0 [redirect_time] => 0 [certinfo] => array ( ) [primary_ip] => 23.65.117.124 [primary_port] => 443 [local_ip] => 192.168.2.142 [local_port] => 63726 [redirect_url] => ) there problem curl. need contact server admin or hosting provider.testing ... https://www.tumblr.com/ - https://www.tumblr.com/ ....https tumblr - ok
as can see, in overall ssl configuration working, reason 2 calls
i got same error. above links opens fine in browser, certificates ca chains valid. reason here?
edit:
i have spend 6 hours try fix this, , find clue going on 2 minutes after posting question on so. have read 1 more time info on http://curl.haxx.se/docs/caextract.html provided extracts there. cought eye (now, not 100 times have read before)
rsa-1024 removed
around september 2014, mozilla removed trust bits certs in ca bundle still using rsa 1024 bit keys. may lead tls libraries having hard time verify sites if library in question doesn't support "path discovery" per rfc 4158. (that includes openssl , gnutls.)
the last ca bundle converted before cleanup: older ca-bundle github.
so took shot , tired budle "before cleanup" - tests passing trough now! question - out-of-date software on mashine openssl, php, curl etc or sites failing on tests has out-of-date certificates format according rfc 4158 , causing troubles?
so question - out-of-date software on mashine openssl, php, curl etc or sites failing on tests has out-of-date certificates format according rfc 4158 , causing troubles?
probably none of these. removed certificates old root-ca 1024bit key. these certificates somehow got replaced newer certificates, not on same place, i.e. if have multiple possible trust path:
host-cert -> intermediate.1 -> 2048bit intermediate.2 -> 1024bit root-ca host-cert -> intermediate.1 -> 2048bit new root
the public key of 2048bit new root
same 1 of 2048bit intermediate.2
, signature intermediate.1
still match chain validation succeed. but, while tls stack try find best chain openssl insists of longest chain. means if server sends chain
host-cert -> intermediate.1 -> 2048bit intermediate.2
then openssl insist on finding root-ca signing intermediate.2
, if has root-ca signing intermediate.1
(i.e. 2048bit new root
). if old 1024bit root-ca
no longer in trust store validation fail. if instead server sends only
host-cert -> intermediate.1
then validation succeed 2048bit new root
. lots of servers still send longer chain maintain compatibility older clients don't have 2048bit new root
.
all ugly , bug reported in 2012 , again in 2015. openssl 1.0.2 (fresh released) has @ least option x509_v_flag_trusted_first
work around problem , there changes in openssl git seem fix issue not clear if every backported 1.0.2 or lower :(
for better keep old 1024bit certificates in trust store.
Comments
Post a Comment