On Fri, Feb 06, 2015 at 11:08:29PM -0700, Bob Proulx wrote: > Marko Randjelovic wrote: > > When I use links2 or elinks web browsers on some websites when https is > > https://webmail.sbb.rs/ > > elinks does not complain about the site. This may be a bug in elinks > as it may be ignoring an error. > > I am able to recreate that problem using links2. And also curl and > wget. elinks gives me this error: > > Verification failure: unable to get local issuer certificate > > curl produces: > > $ curl https://webmail.sbb.rs/ > curl: (60) SSL certificate problem: unable to get local issuer certificate > More details here: http://curl.haxx.se/docs/sslcerts.html > > curl performs SSL certificate verification by default, using a "bundle" > of Certificate Authority (CA) public keys (CA certs). If the default > bundle file isn't adequate, you can specify an alternate file > using the --cacert option. > If this HTTPS server uses a certificate signed by a CA represented in > the bundle, the certificate verification probably failed due to a > problem with the certificate (it might be expired, or the name might > not match the domain name in the URL). > If you'd like to turn off curl's verification of the certificate, use > the -k (or --insecure) option. > > wget produces: > > $ wget -O- https://webmail.sbb.rs/ > --2015-02-06 23:01:30-- https://webmail.sbb.rs/ > Resolving webmail.sbb.rs (webmail.sbb.rs)... 89.216.2.57 > Connecting to webmail.sbb.rs (webmail.sbb.rs)|89.216.2.57|:443... connected. > ERROR: The certificate of ‘webmail.sbb.rs’ is not trusted. > ERROR: The certificate of ‘webmail.sbb.rs’ hasn't got a known issuer. > > With three out of three complaining about the site I diagnose the > problem to be the site and not your browsers. > > When I probe using: > > openssl s_client -connect webmail.sbb.rs:443 > > It shows me this information: > > Certificate chain > 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=webmail.sbb.rs > i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2 > > I think that is insufficient. I am not an expert and hopefully > someone else will jump in with better diagnosis but I believe the site > itself does not include enough of the certificate chain back to the CA > root and therefore the certificate does not verify. When I used > PositiveSSL previously there was an additional > "AddTrustExternalCARoot" certificate which was provided too. > > In the browser cases that do accept it the browser must already have > the chain available to it. If the browser has access to the > intermediate security certificates already then it would be possible > to verify it back to the CA root. Firefox and Chromium both verify > the certificate successfully. Therefore they must already have the > intermediate certs available. > > In summary I think the site itself provides insufficient certificate > information. It needs to provide the intermediate security chain. > > Anyone else on the list have a better diagnosis? When testing an SSL site, I find the SSLLabs test to be nice and clear: https://www.ssllabs.com/ssltest/analyze.html?d=webmail.sbb.rs&hideResults=on&latest Under "Certification Paths", you see how the test navigates from the provided certificate to something that it already trusts. The "Extra Download" warning means that it's been able to identify the signer of the certificate, but has had to download that in order to find the next item in the chain. To solve this, it is usual to create a file like "cat mysite.crt intermediate.crt > mysite-bundle.crt" and use THAT bundle as the certificate file for your site. This provides both certificates to the browser and speeds up verification. Note, also, the rather large number of RED text items on that test, though. > > Bob
Attachment:
signature.asc
Description: Digital signature