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?
Bob
Attachment:
signature.asc
Description: Digital signature