Your connection is not secure problem

[Dempsey]

I am running Firefox browser version 45.0 on Windows 7 Pro x64

When I try to link to for example
https://resourcecentre.globaliris.com/products.html?id=81 I get the
message: "Your connection is not secure. The owner of
resources.globaliris.com has configured their website improperly. To
protect your information from being stolen, Firefox has not connected to
this website."

However, I.E. 11 does not have a problem with that website.

[Good Guy]

No problems here in Windows 10, FF 45.0.  See this picture:

[king-daddy]

I have your same configuration.
I do not get the message.



Carl

[Dave Royal]

Dempsey <pieter....@van-vliet.org> Wrote in message:

Somebody posted a similar problem recently. The culprit was ESET
Smart Security. Do you have that?
--
(Remove any numerics from my email address.)

[Dempsey]

No, I am not using ESET Smart Security, but is it possible that it got
sneaked into my system via other software installs? And if so, where or
what should I look for?

[VanguardLH]

With Firefox 45.0, with or without add-ons (safe mode), I can connect to
that site okay. Have you purged all Firefox caches (clear on exit, or
use a cleaner, like CCleaner) and retried a connection to that site?
They may have had a momentarily problem.

Do you use the HTTPS-Everywhere extension? If so, has it been recently
updated? Sometimes that extension will break a site so you have to wait
until they fix their rules (or the site owner to change something on
their end). For example, http://www.virubtn.com/ uses the Location
header to redirect visitors to their new site at
https://www.virusbulletin.com. They redirect from HTTP (old site) to
HTTPS (new site). The problem is that the rule in HTTPS-Everywhere only
converted http: to https: but the old virusbtn.com site doesn't support
HTTPS. So when HTTPS-Everywhere changed http://www.virubtn.com to
https://www.virusbtn.com then I would get a "server not found" error. I
contacted both Virus Bulletin and HTTPS-Everywhere about the failed
redirect by HTTPS-Everywhere. I do not see that HTTPS-Everywhere
changed their rule. It still simply changes http: to https: (converts
http://www.virusbtn.com to https://www.virusbtn.com) but it looks like
the site owner made some change to his old site. Using the Location
header on his old HTTP site that pointed to his new HTTPS site worked if
HTTPS-Everywhere was involved. See my discussion at:

https://github.com/EFForg/https-everywhere/issues/4273
continued at:
https://github.com/EFForg/https-everywhere/pull/4280

Seems the rule set for HTTPS-Everywhere has to keep getting updated via
user reports where this extension breaks a web site. In the virusbtn
case, their rule was for the old site (when it did support or have a
valid cert for the HTTPS connect to that site). Then the site went to a
different domain and the old rule (still the current rule) was no longer
valid (until the site owner made a change). I've hit way too many sites
where HTTPS-Everywhere causes problems (usually error pages) that I will
probably discard it. One, it obviously only works at the limited number
of sites for which it has rules. It does not blanket switch all http:
requests to https: requests. No matter how many rules they have, they
will never approach the number of web sites that exist even if only for
those that support HTTPS. So it really is misnamed as HTTPS-Everywhere
and should really be named HTTPS-WhereWeKnowAbout.

Way over a decade ago, Internet Explorer had options to determine if any
mixed (active and image) content was allowed in a supposedly HTTPS
secure web page. Mixed content means HTTP content delivered in an HTTPS
web page: you think the page is secure, see the lock icon, but some
content is not secure. A decade later Mozilla added user-configurable
options for mixed content (HTTP content delivered with a supposedly
HTTPS-secured web page), by default Firefox only blocks *active* mixed
content (security.mixed_content.block_active_content) and not images
(security.mixed_content.block_display_content). That is because LOTS of
sites have insecure images included in their secure web page. For
example, when looking at offers at craigslist.org, their web pages
appear secured but you won't see any images if you also block insecure
content (i.e., if blocking mixed content includes both active and image
content). To see the images at Craiglist, you need to have Firefox (or
any web browser) configured to block mixed (insecure) active content but
allow mixed (insecure) image content. Mozilla doesn't want to break
lots of site that pretend to have secure (HTTPS) content but instead
deliver mixed content.

Mixed content means the secure page is not secure. A page is secure or
it is not, not somewhere between. Because Firefox, by default, allows
some insecure content (images), you'll see a new lock icon at the left
end of the address bar in version 45. On sites, like Craigslist, that
deliver mixed content, the lock icon appears not as green (meaning fully
secure - no mixed content, including no insecure images) but as green
with a yellow hazard overlay. Looking at the details of the partially
secure lock icon doesn't tell you want content was secure. You get an
indication that insecure images are at fault in the message "Parts of
this page are not secure (such as images)". That doesn't explicitly
state that insecure images is the culprit of mixed content (which means
the secure page is not secure).

If you decide to configure Firefox to also block mixed content for
images (security.mixed_content.block_display_content = True) then you
will find lots of sites where images are missing and replace by blank
placeholders.

You should check if whatever security software (anti-virus/malware) that
you use has the ability to interrogate HTTPS traffic. For example,
Avast can do that if the HTTPS scan option is enabled. They install a
cert used in a MITM (Man In The Middle) attack scenario that lets them
intercept the HTTPS traffic to inspect for nefarious content. For some
reason, Mozilla decided to use their NSS tools to manage a private
certificate store used by Firefox instead of using the Windows cert
store (as do IE and Google Chrome). If the antimalware with HTTPS
scanning doesn't insert its cert into Firefox's private cert store than
all HTTPS connects will fail. However, you only mentioned a problem at
a single HTTPS site, not that you had problems at all HTTPS sites. You
gave one site as an example. Was that an example showing what happens
when you visit any HTTPS web site?

[Dave Royal]

On Wed, 16 Mar 2016 15:54:28 -0600, Dempsey wrote:

> On 16-Mar-2016 04:16, Dave Royal wrote:
>> Dempsey <pieter....@van-vliet.org> Wrote in message:
>>> I am running Firefox browser version 45.0 on Windows 7 Pro x64
>>>
>>> When I try to link to for example
>>> https://resourcecentre.globaliris.com/products.html?id=81 I get the
>>> message: "Your connection is not secure. The owner of
>>> resources.globaliris.com has configured their website improperly. To
>>> protect your information from being stolen, Firefox has not connected
>>> to this website."
>>>

>> Somebody posted a similar problem recently. The culprit was ESET
>> Smart Security. Do you have that?
>>
> No, I am not using ESET Smart Security, but is it possible that it got
> sneaked into my system via other software installs? And if so, where or
> what should I look for?

Sorry - the ESET problem was a different error message.

[Dave Royal]

I can access that website OK. But I get that "owner ... has configured
their website improperly" message on Android when accessing an old Netgear
access point. If I look on a desktop machine I see this warning:
Broken encryption (TLS_RCA_WITH_RC4_128_WITH_MD5, 128bit keys, TLS 1.0)
Your connection to this site uses weak encryption...

That globaliris site doesn't use weak encryption here. But I wonder if
something has disabled stronger encryption on your system, forcing it to
negotiate down to a too-weak level. ISTR some recent malware does that -
in order to do an MiM attack or something?

Or that might all be irrelevant.

[»Q«]

In
<news:mailman.420.1458207232...@lists.mozilla.org>,

That seems worth checking out. I dunno too much about this, but I
think the testing page
<https://www.ssllabs.com/ssltest/viewMyClient.html> will show any
problems a client has with weak protocols or ciphers. Since Firefox
refused to connect to the globaliris site, it probably won't show any
problems, but testing IE 11 might turn something useful up.

[VanguardLH]

Dave Royal wrote:

> I can access that website OK. But I get that "owner ... has configured
> their website improperly" message on Android when accessing an old Netgear
> access point. If I look on a desktop machine I see this warning:
> Broken encryption (TLS_RCA_WITH_RC4_128_WITH_MD5, 128bit keys, TLS 1.0)

^^^ ^^^^^^^
/ /
Weren't those removed in a Windows globaliris supports TLS 1.2
update several months ago?

https://redmondmag.com/articles/2013/11/13/broken-rc4-encryption.aspx
https://support.microsoft.com/en-us/kb/2868725

Windows had an update months ago to remove the weak and vulnerable RC4
ciphers soon after the FREAK vulnerability was announced (see
https://en.wikipedia.org/wiki/FREAK). I would have expected Google to
do the same for its Android OS but, according to you, apparently they
have not, or you have not applied updates to the OS. Q mentioned the
SysLabs site you can visit to determine if you are using weak and
vulnerable ciphers on your Android. OpenSSL had to get updated to
remove the vulnerability so perhaps the version that came with your
Android phone has not been updated yet. The globaliris site does
support TLS 1.2 so why is your Android OS only using TLS 1.0? Don't
know the OS on your "desktop" to address why it is still using an old
RC4 cipher and only using TLS 1.0 to connect to that site.

TLS 1.0 is just SSL 3.0 renamed but the protocol handshaking is
sufficiently different so a site that only supports SSL 3.0 won't
connect using TLS 1.0. However, TLS 1.0 will fallback to SSL 3.0 (upon
request from the server) so you may end up using the vulnerable SSL 3.0.

I tried setting Firefox 45.0 under Windows 7 to use only TLS 1.2 by
changing the following in about:config:

security.tls.version.min = 3
security.tls.version.max = 3

See http://kb.mozillazine.org/Security.tls.version.* for what the values
mean. Firefox comes with them set to 1 (min = TLS 1.0) and 3 (max = TLS
1.2). I first tried with 3 and 3 but hit some sites in my bookmarks
that would fail to connect. Then I tried 2 (TLS 1.1) and 3 (TLS 1.2)
and still those sites failed to connect. So I went back to 1 and 3, the
defaults. I want to TLS 1.2 as the minimum for all HTTPS sites. I found
no means within Firefox to configure it to globally use TLS 1.2 on HTTPS
sites but allow exceptions (to use TLS 1.1 or 1.0) at some sites.

Getting back to the HTTPS site where the OP cannot connect, and me using
Firefox 45.0 on Windows 7 (with the cipher update to remove the weak
ones), the cipher used for my connect to there was:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2

So not only am I *not* using RC4 but the site also supports TLS 1.2.

[Dave Royal]

On Thu, 17 Mar 2016 13:27:09 -0500, VanguardLH wrote:

> Windows had an update months ago to remove the weak and vulnerable RC4
> ciphers soon after the FREAK vulnerability was announced (see
> https://en.wikipedia.org/wiki/FREAK). I would have expected Google to
> do the same for its Android OS but, according to you, apparently they
> have not, or you have not applied updates to the OS.

I can't access the old access point on Android: I get the same message as
the OP. I was merely using it as evidence that this message may (repeat
may) result from accessing a site using weak - indeed unsupported -
encryption. (Why I /can/ access it from Fx 45 on desktop (linux) is a
more interesting question, but irrelevant here.)

> Getting back to the HTTPS site where the OP cannot connect, and me using
> Firefox 45.0 on Windows 7 (with the cipher update to remove the weak
> ones), the cipher used for my connect to there was:
>
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2
>

Same here (on desktop, anyway). So the question is, if Fx 45 can support
this strong encryption, and the site offers it, why isn't that happening
for the OP? Is this a protocol downgrade attack?

And I just noticed the gobaliris site front page says they upgraded their
encryption in April last year. Hmmm.

[VanguardLH]

What happened when you visited the SSLlabs site that Q mentioned? For
Windows, the weak ciphers were removed by a Windows update, not by a
Firefox update. So the ciphers are used in the OS because it is the OS
that creates the sockets for the connections, not the web-centric app.

I don't what might've happened, if anything yet, to address that OS' use
of weak ciphers. I would suspect the SSL vulnerabilities would not
disappear until the OpenSSL libs got fixed and then updated in the OS.

[Dave Royal]

VanguardLH <V...@nguard.LH> Wrote in message:

>
> What happened when you visited the SSLlabs site that Q mentioned?
>

Is that Qn to me? On my Android (4.4.4) it's all good.
Firefox/Android supports the weak cipher of my access point if I
whitelist it (security.tls.insecure_fallback_hosts) but Fx
prevents it by default. But the OPs problem (if it's anything to
do with cipher strength) is not unwanted support of weak ciphers
but lack of support for a strong one.

[»Q«]

In
<news:mailman.431.1458261194...@lists.mozilla.org>,

VanguardLH <V...@nguard.LH> wrote:

> For Windows, the weak ciphers were removed by a Windows update, not
> by a Firefox update. So the ciphers are used in the OS because it is
> the OS that creates the sockets for the connections, not the
> web-centric app.

For Firefox on Windows, the bundled NSS handles TLS, using its own stuff
for the ciphers. I'm afraid I don't really have a clue about how to
help with the OP's problem.

[Dempsey]

On 17-Mar-2016 12:27, VanguardLH wrote:
> Getting back to the HTTPS site where the OP cannot connect, and me using
> Firefox 45.0 on Windows 7 (with the cipher update to remove the weak
> ones), the cipher used for my connect to there was:
>
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2
>

> So not only am I*not* using RC4 but the site also supports TLS 1.2.
I admit that this a bit beyond my knowledge level.

I played around with the security.tls.version.min all the way down to 0
and up to 3, still the same problem so the min is back to the default of 1.

However, when you say "with the cipher update to remove the weak ones",
how do I make that update on my system?

Would a profile reset be a solution?

[VanguardLH]

Q wrote:

> For Firefox on Windows, the bundled NSS handles TLS, using its own stuff
> for the ciphers. I'm afraid I don't really have a clue about how to
> help with the OP's problem.

The OP hasn't been back in 3 days. Maybe the problem just went away
(happens too often when you start to investigate).

Looks like I was wrong in the OS handling which ciphers to use. The
update mentioned changes to a new schannel file that removed the RC4
ciphers. Internet Explorer would make use of schannel so not having the
RC4 ciphers means IE cannot use it. Apparently the key to IE not even
trying to use the RC4 ciphers were registry keys that disabled them;
i.e., besides a change in schannel, there were registry changes to tell
IE not to attempt using the RC4 ciphers.

I doubt Firefox is using anything of IE's libs (e.g., schannel) or
registry entries to see RC4 ciphers were disabled there. Mozilla would
need their own separate update to alter the behavior of Firefox. See
https://blog.mozilla.org/security/2015/09/11/deprecating-the-rc4-cipher/.
Mozilla came to this pretty late. Microsoft's KB2868725 came out in
November 2013. Firefox 44 didn't get released until January 2016, over
2 years later.

The OP said they are using Firefox 45 so the old weak RC4 ciphers should
be unavailable in Firefox. I also have Firefox 45 and it connected
without problem to the globaliris web site which makes me wonder what
else is involved in his network setup, like security software
(anti-virus/malware) that might employ HTTPS interrogation (via an MITM
scheme) where its proxy is still using RC4 (when it usurps the roll of
the client connecting to the server). The OP might also want to check
the TLS settings in Firefox. I only know of a couple that I mentioned.
There is a security.tls.insecure_fallback_hosts setting where you can
comma-delimit list the server names for HTTPS sites that do not support
TLS (and still require SSL) so that might be something to check. For
me, that setting is empty (no listed hosts).

[»Q«]

In
<news:mailman.502.1458331947...@lists.mozilla.org>,

Dempsey <pieter....@van-vliet.org> wrote:

> I admit that this a bit beyond my knowledge level.
>
> I played around with the security.tls.version.min all the way down to
> 0 and up to 3, still the same problem so the min is back to the
> default of 1.

> Would a profile reset be a solution?

It wouldn't hurt to try it, but I doubt that alone will help. I think
if I were in your shoes I would do a profile reset and then download
and run a fresh Firefox installer. The reset should put all the
TLS-related prefs back to their defaults, and the fresh install should
re-install all of NSS (which handles all the TLS stuff for Firefox).

If that doesn't work, I think there's something fishy going on
somewhere between your Firefox and that site, but I wouldn't know how
to get to the bottom of it.

[Christian Riechers]

On 03/18/2016 09:12 PM, Dempsey wrote:
> On 17-Mar-2016 12:27, VanguardLH wrote:
>> Getting back to the HTTPS site where the OP cannot connect, and me using
>> Firefox 45.0 on Windows 7 (with the cipher update to remove the weak
>> ones), the cipher used for my connect to there was:
>>
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2
>>
>> So not only am I*not* using RC4 but the site also supports TLS 1.2.
>
> I admit that this a bit beyond my knowledge level.
>
> I played around with the security.tls.version.min all the way down to 0
> and up to 3, still the same problem so the min is back to the default of 1.

Don't mess with these settings unless you know what you're doing.

> However, when you say "with the cipher update to remove the weak ones",
> how do I make that update on my system?

Keep your Firefox up to date. Simple as that.

> Would a profile reset be a solution?

May be.
Even though it's for a different error code, I'd first have a look at
this article.
https://support.mozilla.org/en-US/kb/troubleshoot-SEC_ERROR_UNKNOWN_ISSUER

[Christian Riechers]

What information is given if you press the 'Advanced' button?

Also see
https://support.mozilla.org/en-US/kb/what-does-your-connection-is-not-secure-mean

[VanguardLH]

The Windows update from Microsoft affects schannel (and some other
files) that clients, like Internet Explorer, can use to make secure
connections. So when Microsoft updated components in their OS to remove
RC4 ciphers (both with new version files and some registry entries), it
affected Internet Explorer, HTAs, or any program that uses the "IE libs"
to do secure connects. Presumably you have all Windows updates (except
maybe those that are Win10 lures); however, all the Windows updates
won't affect Firefox, anyway.

Mozilla doesn't use Microsoft stuff like this. You have to upgrade to a
version of Firefox where the NSS tools used to build its cipher support
were updated to remove the weak ciphers. That means upgrading to a
later version of Firefox. According to the blog article to which I
linked, the weak ciphers should have disappeared in Firefox 44. Since
you are up to version 45, something else must be wrong when trying to
connect to the globaliris site using HTTPS. That's why I proposed one
possible cause for interference would be anti-virus/malware software
that has the feature to inspect HTTPS web traffic (e.g., Avast). This
requires a MITM scheme to intercept the encrypted traffic, decrypt it
for inspection, and re-encrypt to pass the traffic to the other endpoint
(depending on which way the traffic flows).

When you look at the cert details when connecting to the globaliris
site, what cipher is listed for that connection? Click on the green
padlock icon in the address bar at the left end, click the rightware
chevron to see details, click "More Information", and look under
"Technical Details" to see what string is listed for "Connection
Encrypted". The cipher details are within the parenthesis.

As possible troubleshooting steps, disable all extensions or start
Firefox in its safe mode and retest. Make sure Firefox is NOT
configured to use a proxy. You never mentioned using a VPN or Tor.
Disable your anti-virus software or try rebooting Windows into its safe
mode (with networking) to retest.

[Dempsey]

I would love to see the error and/or cause of the not secure issue too.
But all I get is the message, a link to general discussion like you
pointed out, and a Go Back button. There is NO Advanced button. The only
Advanced button I know of is the one under Options, but that one does
not show the error.

I believe until FF 43.0 there was an Advanced button that goes with the
stated message. Is there a setting that gets me back the Advanced button?

[»Q«]

In
<news:mailman.519.1458410041...@lists.mozilla.org>,

Without being able to see what you're seeing, it's hard to say, but I
think the Advanced button is missing only in cases where the security
problem is so 'bad' that Mozilla have decided not to give the user a
way to override it and that there's no way to make the button appear.
You might be able to get more info by clicking the icon to the left of
the URL in the address bar.

[Dempsey]

What I see is shown on http://www.van-vliet.org/filetrans/notsecure.jpg
..At the top the message that FF generates. Below that what I see when I
click on the icon before the URL and then click on the left-arrow of the
top item.

[»Q«]

In
<news:mailman.524.1458419241...@lists.mozilla.org>,

I'm afraid I'm only more confused than ever. You'd only get the
'Advanced' button if Firefox thought encryption was offered and that
something was wrong with the encryption, but your Firefox is telling you
that 'the site does not offer encryption for the page you are
viewing.' OTOH, if Firefox thinks no encryption is offered, it
shouldn't be throwing up any security warnings at all, let alone
blockers.

Your Firefox seems to be confused in multiple ways, and I certainly
am. Unless someone here comes up with a brilliant new idea, you might
have better luck taking this to <https://support.mozilla.org/>.

[Dempsey]

On 19-Mar-2016 15:49, »Q« wrote:
> I'm afraid I'm only more confused than ever. You'd only get the
> 'Advanced' button if Firefox thought encryption was offered and that
> something was wrong with the encryption, but your Firefox is telling you
> that 'the site does not offer encryption for the page you are
> viewing.' OTOH, if Firefox thinks no encryption is offered, it
> shouldn't be throwing up any security warnings at all, let alone
> blockers.
>
> Your Firefox seems to be confused in multiple ways, and I certainly
> am. Unless someone here comes up with a brilliant new idea, you might
> have better luck taking this to<https://support.mozilla.org/>.

OK, I did run FF with add-ons disabled (safe mode).

When I go to the Global Iris link I do get the unsecure error message,
but also the Advanced button (hurray):
http://www.van-vliet.org/filetrans/notsecure1.jpg

When I click on the error code I get this:
http://www.van-vliet.org/filetrans/notsecure2.jpg

When I click on Add Exception and then View I get this:
http://www.van-vliet.org/filetrans/notsecure3.jpg

To my untrained eye the certificate looks good it is just that FF does
not recognize something that it should.

[»Q«]

In
<news:mailman.562.1458432764...@lists.mozilla.org>,

Dempsey <pieter....@van-vliet.org> wrote:

> OK, I did run FF with add-ons disabled (safe mode).
>
> When I go to the Global Iris link I do get the unsecure error
> message, but also the Advanced button (hurray):
> http://www.van-vliet.org/filetrans/notsecure1.jpg
>
> When I click on the error code I get this:
> http://www.van-vliet.org/filetrans/notsecure2.jpg
>
> When I click on Add Exception and then View I get this:
> http://www.van-vliet.org/filetrans/notsecure3.jpg
>
> To my untrained eye the certificate looks good it is just that FF
> does not recognize something that it should.

The certificate is good -- that's the same cert (its fingerprints
match) which is accepted by everyone else's Firefox. By default,
Firefox trusts the issuer.

The fact that your Firefox behaves differently in safe mode makes it
seem likely that one of your add-ons is monkeying with the way Firefox
handles certs. Also, something (maybe that same add-on) seems to have
taken the Symantec issuer cert out of Firefox's trusted cert store.

I think I'd refresh/reset the Firefox profile as well as re-install
Firefox itself.

[Christian Riechers]

I have posted this before. Not sure why people don't read and try what
has been suggested.
https://support.mozilla.org/en-US/kb/troubleshoot-SEC_ERROR_UNKNOWN_ISSUER

[Christian Riechers]

See
https://support.mozilla.org/en-US/kb/troubleshoot-SEC_ERROR_UNKNOWN_ISSUER

Symantec are trying to 'protect' you by intercepting the secure
connection to the server.
This creates a huge attack surface, so you must have a lot of faith in
Symantec. I wouldn't.

[Dave Royal]

Christian Riechers <chrie...@netscape.net.invalid> Wrote in message:

> Symantec are trying to 'protect' you by intercepting the secure
> connection to the server.
> This creates a huge attack surface, so you must have a lot of faith in
> Symantec. I wouldn't.
>

That's what ESET was doing in the other case I mentioned.

ssllabs has an enquiry to check the server. I ran it 2 days ago to
check the available ciphers, and saw that issuer chain error.
There are some other weaknesses too but none likely to have
caused the OP's problem.

[VanguardLH]

How did the discussion move from the OP connecting to globaliris to
something to do with Symantec? Did some Norton security program sneak
into the discussion that I missed? Considering all the unknown and
hard-to discover-who-they-are CAs, Symantec is well known.

Symantec is the CA, not the globaliris site that can configure their
server regarding what ciphers it will support and which it will request
fallback (at the client) to get to one it does support. Why is Symantec
any worse a CA than is Comodo, Verisign, Thawte, or the myriad of other
CAs listed in Firefox's private certificate store? Every heard of
BuyPass, Chunghwa Telecom, Dhimyotis, HongKong Post, or many of the
other CAs listed in Firefox's private cert store (or those included in
the OS [global] cert store that Firefox won't use? Mozilla decided to
add those CAs into Firefox's private cert store, so if you suspect
something wrong with Symantec as a CA then complain to Mozilla. The
number of CAs has gotten way out of hand. I don't remember where
reading it but someone reported on the total number of CAs and it was
several hundred.

[Nobody]

Look at OP Dempsey's screen shots five steps back up the thread!

[»Q«]

In
<news:mailman.553.1458489851...@lists.mozilla.org>,

They show Symantec as the issuer of the site's cert. That's exactly
what I see from here as well, without any Symantec products installed.
But certainly Dempsey should go through the stuff at the SUMO link
Christian posted.

[VanguardLH]

Nobody wrote:

> Look at OP Dempsey's screen shots five steps back up the thread!

Yes, I already recognized that Symantec is the CA (certificate
authority). What does that have to do with Symantec being untrusted as
per Riecher's statement?

That a certificate has being and expiration dates specified within it
does NOT mandate that is when the certificate will expire. Anyone that
gets a certificate can revoke it plus it can be revoked for abuse. So
the client still has to connect to the CA to find out if the certificate
is okay.

As I mentioned, Mozilla decided to use a *private* certificate store in
Firefox. When I look at Firefox's private cert store, Symantec is
listed but under Verisign; that is, Verisign actually generated the
certificate for Symantec as an intermediary. In Firefox, Options ->
Advanced, Certificate tab, view certificates, scroll down to Verisign.
There you will should find "Symantec Class 3 EV SSL CA - G3" root cert.
Is Symantec's root cert still defined in the OP's instance of Firefox?

Also, to find out if a cert is still valid requires retrieving a
revocation list (the old CRL scheme) or querying an OSCP server (to ask
if a cert has been revoked). The cert lists the CRL's (cert revocation
list's) URL to know where to connect to check on cert revocation. Can
the OP reach http://sr.symcb.com/sr.crl to retrieve the 98KB file to
then check if the site's cert has been revoked via CRL? Can he connect
to http://sr.symcd.com to query the OSCP server? Validating a cert is
still alive requires other network routes than the visited web site and
sometimes a node (hop) in a route is down or unresponsive, and routing
is not dynamic to immediately find alternate routes.

If the client cannot check if a cert has been revoked then the client
does not know that a site's cert is still valid. I don't know how
Firefox handles not being able to connect to the CRL or OSCP server to
determine validity of a cert.

I'm not sure that the problem is his client cannot reach a CRL or OSCP
server to validate a cert. The sec_error_unknown_issuer error seems
more like he doesn't have the root cert for Symantect in Firefox's
private certificate store (but it is there in the Windows [global] cert
store since he connects okay using Internet Explorer - and since Google
Chrome also uses the Windows cert store than that web browser should
work as well). From reading other users reporting that error in
Firefox, other web browsers worked just fine (because they use the OS
cert store) and the fix required installing a CA cert into Firefox's
private cert store. One response was:

Firefox is more stringent than other browsers and will require proper
installation of an intermediate server certificate [into Firefox].
This can be supplied by the cert authority the certificate was
purchased from. the intermediate cert is typically installed in the
same location as the server cert and requires the proper entry in the
httpd.conf file.

while many are chastising Firefox for it's (generally) exclusive
'flagging' of this, it's actually demonstrating a higher level of
security standards.

More security perhaps. More breakage for sure. This is probably due to
sites (not the CA, which is Symantec, in this case) doesn't properly
implement a certificate chain that links their certificate issued from a
intermediary instance to the root certificate authority trusted by the
browser. Of course, not having the certs in the local store (private in
Firefox's case) means no validating the cert at all.

I ran the globaliris site (just there domain, not the complete URL)
through https://www.sslshopper.com/ssl-checker.html. It indicates there
is a problem with cert implementation at the site for some web browsers.
https://www.sslshopper.com/ssl-certificate-not-trusted-error.html,
"missing chain", is perhaps a cause of the cert problem at globaliris
but it could also be a problem of not having the required cert in
Firefox's private cert store.

Go to https://www.ssllabs.com/ssltest/index.html and test the site
(https://resourcecentre.globaliris.com) there and you will see they find
a chaining error. Look at the certification path section. Then visit
https://www.digicert.com/help/ and test on that site again. They note
(highlighting added):

SSL Certificate is not trusted
The certificate is not signed by a trusted authority (checking against
/*Mozilla's*/ root store). If you bought the certificate from a
trusted authority, you probably just need to install one or more
Intermediate certificates. Contact your certificate provider for
assistance doing this for your server platform.

My response to Riechers, again, is why does he mistrusts Symantec as a
certificate authority. The problem is not with Symantec. The problem
is with the site's cert config or perhaps with the private cert store
for the OP's instance of Firefox.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/

Since I have Symantec's cert in my instance of Firefox, presumably that
got there because Mozilla qualified its inclusion in Firefox's private
certificate store. If Mozilla trusts Symantec as an [intermediary] CA
then why doesn't Riechers? I know that some of the free SSL CAs aren't
in Mozilla's list or the included cert store in Windows. Users have to
manually import the cert into the global/private cert store so a site
using one of the free certs can be validated.

[»Q«]

In
<news:mailman.565.1458517347...@lists.mozilla.org>,

VanguardLH <V...@nguard.LH> wrote:

> As I mentioned, Mozilla decided to use a *private* certificate store
> in Firefox.

It's not any more or less "private" than the stores any other program
vendors user, in any sense that I know of.

[Dempsey]

On 15-Mar-2016 22:16, Dempsey wrote:
> I am running Firefox browser version 45.0 on Windows 7 Pro x64
>
> When I try to link to for example
> https://resourcecentre.globaliris.com/products.html?id=81 I get the
> message: "Your connection is not secure. The owner of
> resources.globaliris.com has configured their website improperly. To
> protect your information from being stolen, Firefox has not connected to
> this website."
>
> However, I.E. 11 does not have a problem with that website.

First I like to thank everyone for their suggestions and help. I
certainly learned a bit more about certificates.

This is what I eventually did based on the suggestions. I did a
Refreshed Profile --> no success.

Then I uninstalled FF 45.0 and did a clean install of FF 45.0.1 --> no
success.

I figured that I should continued customizing FF 45.0.1 while I am this
far, especially in the History settings under the Privacy options (Use
custom settings for history, and Always use private browsing mode) and
ensuring that upon FF exit not history is kept, like I have always done.
To the best of my knowledge all my Options are the same as under FF45.0
and previous version.

Then I tried the Global Iris webpage again and suddenly it is working fine.

[Christian Riechers]

On 03/20/2016 10:03 PM, VanguardLH wrote:
> Since I have Symantec's cert in my instance of Firefox, presumably that
> got there because Mozilla qualified its inclusion in Firefox's private
> certificate store. If Mozilla trusts Symantec as an [intermediary] CA
> then why doesn't Riechers? I know that some of the free SSL CAs aren't
> in Mozilla's list or the included cert store in Windows. Users have to
> manually import the cert into the global/private cert store so a site
> using one of the free certs can be validated.

I was jumping the gun and didn't realize from the screenshot the OP
provided that the Symantec cert was indeed the trusted CA cert, and not
one of those locally generated SSL proxy certs certain anti-virus
software vendors use to intercept SSL/TLS connections.
That is a problem in many ways, but it seems Symantec don't do that.

What fixed the problem for the OP I don't know. It may have been some
sort of corruption of the local FF certificate store which mysteriously
cleared up itself.

I was able to connect to the site the OP had a problem with just fine.