Closed Bug 1489549 Opened 6 years ago Closed 5 years ago

ESR 60.2.0 x64 | Some self-signed certificated imported from the Windows root store is not accepted

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
60 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1473573

People

(Reporter: o.pfaefflin, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

https://support.mozilla.org/en-US/questions/1227998

Configured FF GPO "use Windows store root CAs"


Actual results:

security.enterprise_roots.enabled locked true

Cert is not accepted though, and throws the usual prompt (SEC_ERROR_UNKNOWN_ISSUER).


Expected results:

My self-signed CA should have been recognized.

Works in Chrome and IE.

See https://support.mozilla.org/en-US/questions/1227998 for what I tried so far, as well as additional infos regarding CNAME etc.
Ah, it's self signed.

we require that even self signed certs be tied to a root. I don't totally understand it though.

Dana, do we have an explanation somewhere?
Flags: needinfo?(dkeeler)
There's some documentation on certificates and the web pki here: https://wiki.mozilla.org/SecurityEngineering/x509Certs
Basically for this to work, you need to create a certificate authority (CA) capable of issuing server certificates. The CA goes in the Windows registry (make sure to mark it as trusted for TLS server authentication). Using that CA, issue a server certificate. This is what the web server uses. Let me know if that works?
Flags: needinfo?(dkeeler) → needinfo?(o.pfaefflin)
Hi,

I suspected something like this and actually tested
> https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Generate_your_CA_Root_2
even before posting in the support forums.

So I had a CA -> intermediate CA -> cert chain.

Don't quite remember all details now though, because this was like 2 months ago now.

I will give it another try during the next few days and update you on it.

- - - - - - -

*Some* hint regarding "we require that even self signed certs be tied to a root." in the error message would avoid people going into searchmode, so I would well appreciate that.

E.g. in my case it made me question if I did something wrong importing/designing the cert into the OS store, which got even more confusing because Chrome/IE handled it just fine.

Best regards
Hi, do you have some updates on this issue?
I believe I'm running into the same issue and my Googling lead me here.  I'm running Quantum 60.2.1esr in our corporate environment while an internal website works fine in IE and Chrome it fails in Firefox with SEC_ERROR_UNKNOWN_ISSUER.  I have confirmed that our ca.domain.com is listed as a root certificate and that our intermediate certificate shows up in the Intermediate Certification Authorities via the Certificates MMC Snapin in our Windows 10 x64 OS.  I have also confirmed that security.enterprise_roots.enabled is set to true.  

If I export our intermediate cert and import it into Firefox's certificate manager then the site starts working.

Let me know if I can grab any more info to help you troubleshoot this but it seems like there is a bug in that the security.enterprise_roots.enabled = true isn't working.

Thanks!
Troy, is your server sending the intermediate certificate in the TLS handshake?
Flags: needinfo?(troysackett)
Sorry I should have mentioned that.  Yes it is using the intermediate cert.
Flags: needinfo?(troysackett)
Hi,

sorry I didn't answer for so long, but I can only work on the issue if no other priorities come up - additionally I got sick lately - Murphy :)

I am still planning to reconfigure everything with CERT -> INTER -> CA and am currently looking forward to being able to do this next week (big project this week which took the time from me the last weeks).

Best regards
Alrighty.

After an 1 hour fight with the openssl CLI to get subjectAltName working[1] and a small fight with getting it into the java keystore...it's working.

[1] Somehow this is completely ignored if following https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Running_your_Own_CA_2

So I probably went sideways somewhere when following said guide a month ago.

I will post a followup with details tomorrow, specific commands I ran etc. for other people who find this thread.

- - - - - - -

One new question though: Funnily enough with the new structure something else broke.
With the current (old) setup we are able to call https://CNAME *without* adding .CORP.local and the site will open just fine.
This breaks with the new setup and throws different errors depending on the browser.

I would suspect this is rooted in some kind of loose config of our current cert setup?
And in turn I suspect it is best to avoid wanting this to work and simply redirect queries for the non-FQDN to the FQDN address?
Or is this some flag I could set somewhere that doesn't break anything security-wise?

[Old and new HOST cert had CN=HOST.CORP.LOCAL and subjectAltName=DNS:HOST,DNS:CNAME.CORP.LOCAL,DNS:CNAME
With new config this throws errors until I kick out the non-FQDN entries.]
Flags: needinfo?(o.pfaefflin)
Regarding the new question: Yup, seems SearchDomains are not supported.

https://stackoverflow.com/questions/33907023/wildcard-cert-marked-invalid-when-not-specifying-fqdn-even-though-its-in-searc

So that'll be solved via a redirect from https://CNAME to https://CNAME.CORP.LOCAL
Hey,

so here is the promised step-by-step set of CLs I ran to get to a running state.
All in guidance of https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Running_your_Own_CA_2

> Outputs (if something was emitted)
# comments when deviating from the Mozilla guide.
Of course you have to to adjust things like DNS names, CNAMEs, country codes, etc. to your needs.
OpenSSL is OpenSSL 1.0.2k-fips  26 Jan 2017
OS is CentOS Linux release 7.5.1804 (Core)
Latest patches installed

You can check your created certificate files (pem) via
openssl x509 -in CERT.pem -text -noout

- - - - - - -

u.O post character limit - follow me -> https://pastebin.com/UngwMuus

That's it - you should now have a workin RootCA -> InterCA -> Host chain.

- - - - - - -

Since our use case is a Tomcat (Atlassian Confluence)
Well, why not make another... -> https://pastebin.com/kdKxG8ab

- - - - - - -

As for this bug, I guess we can close it? :)

Best regards
Oliver
Okay buggrabber seems to be more familiar with Certs than I am.  So if I run through all the instructions on that developer.mozilla.org link and assuming I do everything correctly what should I expect to see when I check my pem files using that "openssl x509 -in CERT.pem -text -noout" command?  In other words how do I know I did it correctly because from what I can tell my certs already have a Root -> Intermediate path.


Thanks for helping a cert newbie out
If you want to check for correct inheritance from root -> inter -> cert you should check
> Issuer: C=XX, O=STUFF, OU=STUFF"
on the intermediate CA and the host cert.

The intermediate CA cert should list the root, and the host cert the intermediate CA.
If you want to countercheck, simply load them into a Windows client via certmgr.msc

As for the host cert, I only checked this in addition to the inheritance
> X509v3 Subject Alternative Name:
>                 DNS:HOST.CORP.local
I will set component Opreations: Deployment Requests so the issue will not remain untriged.
Component: Untriaged → Operations: Deployment Requests
Product: Firefox → Cloud Services
I think is the right component for this bug
Component: Operations: Deployment Requests → Enterprise Policies
Product: Cloud Services → Firefox
Version: 60 Branch → unspecified
The Enterprise Policies part of this setting is working correctly, the issue is some problem that makes the certificate to not be accepted. I'm gonna move this to a different component and reword the bug title to try to be more accurate. Please edit it if I didn't get it right..
Component: Enterprise Policies → Security: PSM
Product: Firefox → Core
Summary: ESR 60.2.0 x64 | Windows domain + GPO cert deployment + GPO "FF: use Windows cert store" → ESR 60.2.0 x64 | Some self-signed certificated imported from the Windows root store is not accepted
Version: unspecified → 60 Branch

If you run Firefox with the environment variable "MOZ_LOG" set to "pipnss:4" (just open and close Firefox, really), what output do you see? (maybe attach a text file to this bug).

Flags: needinfo?(o.pfaefflin)

As described in comments #9-11 it is working now.

The initial issue was that I didn't find any info on

we require that even self signed certs be tied to a root. I don't totally understand it though.
because the error message is just a generic "issuer is unknown!".
So that caused massive confusion as to why Firefox didn't like my self-signed cert, but Chrome/IE did.

After setting up the root -> inter -> cert chain (correctly :D) it worked.

This setup is in action since early November 2018 on our reverse proxy and has proven to work properly for all browsers (no idea on Apple stuff, don't really care too :)).

So if someone on the FF dev team wants to improve on this, I'd propose this:

Other than that, the functionality itself is fine - once you know what FF expects you to do ;)

Flags: needinfo?(o.pfaefflin)

So that caused massive confusion as to why Firefox didn't like my self-signed cert, but Chrome/IE did.
was not part of the original quote, but I don't see an edit button anywhere :O

So that caused massive confusion as to why Firefox didn't like my self-signed cert, but Chrome/IE did.

do I need double line breaks or what :>

Obviously I am not a security guy, just the guy getting software to work for enterprise deployments. But I don't understand why our self-signed certs work fine in Chrome or IE only. I though maybe it was a security issue so I brought it up with our security team and they were unconcerned. So feels like a bug to me.

I never could get the cert to re-order to anything than what it already is in our environment so at this point everyone is using Chrome/IE for those internal sites that fail.

I tried to grab the log file that was requested by running this command:
firefox.exe -MOZ_LOG=timestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,pipnss:4 -MOZ_LOG_FILE=%TEMP%\log.txt "https://internal_service_page_URL_that_is_having_the_issue"

But no log file is generated. Is this no longer a good way to capture the data you asked for?

Got the command from:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

But I don't understand why our self-signed certs work fine in Chrome or IE only.

Read above

we require that even self signed certs be tied to a root.

Firefox has tighter requirements for self signed certs.
For your setup to work in Firefox, it needs to be a chain of rootCA -> interCA -> HostCert.

You can use my PasteBin links in comment #11 to create those.

You're a trooper Buggrabber. You have been quite clear on the rootCA -> interCA -> HostCert and I have no confusion there. But the steps required to get a cert to be that way is not clear at all to me. I gave it the 'ol college try but couldn't get it to work. I reached out to people that deal with certs all the time (our sec. team) and they didn't agree that anything needs tightened in our enterprise just for Firefox. So now I'm stuck and so our users just don't use Firefox to access these tools.

But here's part of my confusion. When I go to one of these problem sites with Chrome and look at the certificate and the Cert path is says CAServer1.ourdomain.com -> Enterrpse-CA-Server (that's the InterCA right?) -> website.domain.com and all those certs come back as OK, so that looks right to me based off of what I'm reading here. But if I use Firefox to view the cert hierarchy it only shows website.domain.com and not the first two like in Chrome.

Ok - there's a few things going on here, but I think they will be generally covered by other bugs.
First is that Firefox doesn't import 3rd party intermediates from the OS. We're planning to change that in bug
1473573. (Firefox also doesn't attempt to fetch intermediates via AIA chasing, whereas Chrome does - that's sort-of a separate issue that will be largely addressed by bug 657228 except in enterprise cases, where bug 1473573 will basically be as close as we can get. Note that the TLS specification mandates that servers send all necessary intermediates in the handshake, so we're working around misconfigured servers anyway.)
Second is the server certificates as its own trust anchor issue. Allowing this caused some issues in the past, so we explicitly disallowed it, but apparently some servers depend on it so we're considering allowing it again in bug 1515608.
Let me know if there are any remaining issues here.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

Thanks Dana and Buggrabber. That other bug's information does seem to fit better with what I'm seeing. I'll start following it instead. Appreciate it

You need to log in before you can comment on or make changes to this bug.