Issue with SSL certificates in some chrome browsers

[Ajay Choudary]

Hi,

When i try to open Https connection from chrome(Android), 

It is giving alert  "Your connection is not private" 

NET::ERR_CERT_AUTHORITY_INVALID

The Certificates are issues by COMODO CA Limited, valid till 2018

And using openssl version is 1.0.1e.

Cases:

-> Same server connecting properly from Desktop (Chrome/Firefox) and few mobiles as well.

-> Same Browser is accepting the same certificates provided by different sub-domain. The only difference is working domain is running with Apache httpd server and non working domain is running on microHttp/libwebsocket/asterisk.

-> Both working and not working servers are in same network and using the same certificates.

If i forcefully allowed from advanced setting then everything works fine with red color cross mark.

How can i resolve this issue? Is it with any cipher mismatch, how to debug it ?

Regards,

Ajay

[PhistucK]

You mentioned it yourself... Apache works, the others do not work. They must be doing something funny.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/96bc0552-be08-4b97-b33b-7437426e3005%40chromium.org.

[David Benjamin]

It's possible you are missing an intermediate certificate. Android's certificate verifier is a bit less tolerant of misconfigured certificates as I recall. Is it a public server that we could look at? If so, what's the URL.

Also, could you send a net-export log per these instructions? Thanks!
https://dev.chromium.org/for-testers/providing-network-details

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CABc02_KCeVpnh01VZVRyV%3DctjL70Y8_5jU%2BDB7Rrkx_ApJO9fw%40mail.gmail.com.

[Ajay Choudary]

@Phistuck, Apache is working for both Mobiles & Desktop, other are working in Desktop and few mobiles.

What is difference b/w Chrome for Android and Chrome for Desktop ? 

Browser is showing the same certificate information in both  working/non-working, how to debug it ?

@David, i was unable to export logs from chrome-mobile net-internals.

Please try below beta urls which are also having same problem.

https://im1.beta-wspbx.com & https://partners.beta-wspbx.com are  working fine 

https://rtc1.beta-wspbx.com is not working.

please suggest

Thanks,

Ajay

[Ryan Sleevi]

On Tue, Sep 8, 2015 at 9:10 AM, Ajay Choudary <aja...@gmail.com> wrote:

@David, i was unable to export logs from chrome-mobile net-internals.

Please try below beta urls which are also having same problem.

https://im1.beta-wspbx.com & https://partners.beta-wspbx.com are  working fine 

https://rtc1.beta-wspbx.com is not working.

please suggest

David was correct. Your server is misconfigured and thus will break with a variety of clients (Android clients, OpenSSL-using applications, Firefox users who have not first been to a Comodo-certified site in the same browsing session as when they load your site)

https://www.ssllabs.com/ssltest/analyze.html?d=rtc1.beta-wspbx.com&latest clearly calls this out.

To be fair, https://www.ssllabs.com/ssltest/analyze.html?d=partners.beta-wspbx.com&latest is also misconfigured, in that it's sending an additional certificate - the root - unnecessarily. But it's easier to ignore extra data then it is to ignore the data you don't have.

You should examine your HTTP server configuration documentation on how to send intermediates. Your CA (Comodo) may also be able to assist you via their support line. This isn't a Chrome bug - this is behaving exactly as specified. 

[Ajay Choudary]

Hi Ryan,

Pl check below shared SSL handshake pcap files of both working(im1.beta-wspbx.com) & non-working (rtc1.beta-wspbx.com).

Here CA is GoDaddy, using the same certificates in both of them.

Working domain is configured on Barracuda & non-working is configured to Asterisk server.

In my asterisk server, i was configured with certificate, key & bundle files in PEM format. (i hope CSR is not required)

and using openssl-1.0.1x internally.

Reading the certificates with 

SSL_CTX_use_certificate_file(cfg->ssl_ctx, cfg->certfile, SSL_FILETYPE_PEM)

SSL_CTX_use_PrivateKey_file(cfg->ssl_ctx, tmpprivate, SSL_FILETYPE_PEM)

PCAP Files:

nonWorkingRTC.pcapng

workingIm1.pcapng

How can i generate intermediate certificates?  

There are many servers are running with asterisk/microHttpd/libwebsockets etc, so every one need to fix them? 

Regards,

Ajay

[Ryan Sleevi]

On Wed, Sep 9, 2015 at 7:54 AM, Ajay Choudary <aja...@gmail.com> wrote:

In my asterisk server, i was configured with certificate, key & bundle files in PEM format. (i hope CSR is not required)

and using openssl-1.0.1x internally.

Reading the certificates with 

SSL_CTX_use_certificate_file(cfg->ssl_ctx, cfg->certfile, SSL_FILETYPE_PEM)

SSL_CTX_use_PrivateKey_file(cfg->ssl_ctx, tmpprivate, SSL_FILETYPE_PEM)

Again, your CA should be able to help you configure your server to properly supply their intermediates.

In this case, you need to make sure that cfg->certfile (the one you're supplying to SSL_CTX_use_certificate_file ), has not only the leaf cert (your server cert), but the intermediates. It should be a single PEM file, where the contents are the server certificate, followed by the Intermediates.

Contacting your CA is the best step, as they're best able to tell you the intermediate(s) you should configure for maximum support.

(I'm not trying to not give you advice, but your CA is really in the best place to advise you how to configure in a way that won't cause issues; I can only point you to one possible config)

This isn't really an issue for net-dev though.

[David Benjamin]

On Wed, Sep 9, 2015 at 11:10 AM Ryan Sleevi <rsl...@chromium.org> wrote:

On Wed, Sep 9, 2015 at 7:54 AM, Ajay Choudary <aja...@gmail.com> wrote:

In my asterisk server, i was configured with certificate, key & bundle files in PEM format. (i hope CSR is not required)

and using openssl-1.0.1x internally.

Reading the certificates with 

SSL_CTX_use_certificate_file(cfg->ssl_ctx, cfg->certfile, SSL_FILETYPE_PEM)

SSL_CTX_use_PrivateKey_file(cfg->ssl_ctx, tmpprivate, SSL_FILETYPE_PEM)

Again, your CA should be able to help you configure your server to properly supply their intermediates.

In this case, you need to make sure that cfg->certfile (the one you're supplying to SSL_CTX_use_certificate_file ), has not only the leaf cert (your server cert), but the intermediates. It should be a single PEM file, where the contents are the server certificate, followed by the Intermediates.

Minor correction: that API can't load a certificate chain. OpenSSL certificate configuration is a huge mess, but the short answer is to use SSL_CTX_use_certificate_chain_file to load a bunch of them like that.

But, yes, like Ryan said, contact your CA and consult the documentation for whatever SSL implementation you're using.

 

Contacting your CA is the best step, as they're best able to tell you the intermediate(s) you should configure for maximum support.

(I'm not trying to not give you advice, but your CA is really in the best place to advise you how to configure in a way that won't cause issues; I can only point you to one possible config)

This isn't really an issue for net-dev though.

--

You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvY3mT5L7Fd6pFunOFNC0%2BXhD5%3D0bPZnui9MU7-m4ek0FQ%40mail.gmail.com.