Description of the issue:
I have a on premise instance of Bitwarden installed on my network, and as it will not be accessible from outside my network, I have set it up using my internal ‘.local’ domain. I have used Active Directory Certificate Services to issue a certificate for it, and I have made sure that the root CA certificate is installed in the certificate store on my PC. When going to the Bitwarden server using Internet Explorer, I do not get any certificate warnings or errors, and looking at the certificate properties, it’s reported as ‘OK’. In brave, when I go to the servers URL, I get the ‘usual’ ‘Your connection is not private’ message. If, in Brave, I go to Settings, Privacy and Security and Manage Certificates, it brings up what appears to be an element of the Windows certificate store MMC snap-in. When I go to the ‘Trusted Root Certification Authorities’ tab and scroll down, I can see the root CA certificate for my internal Certification Authority is present in the list. Despite the root CA certificate being installed, Brave still does not trust the certificate. Is Brave doing something else regarding the trusting of certificates? Is there a way to get Brave to trust the certificate properly?
How can this issue be reproduced?
Go to URL of server.
Expected result:
Be presented with the web login with no certificate errors.
Brave Version( check About Brave):
1.31.87 Additional Information:
It’s actually not giving ‘NET::ERR_CERT_AUTHORITY_INVALID’, it’s giving ‘NET::ERR_CERT_COMMON_NAME_INVALID’, but the CN is correct.
Below is Braves message and the certificate path info/status as seen from IE. Interestingly, when I click ‘Not Secure’ in Brave and click ‘Certificate (Invalid)’, I get the exact same window that doesn’t indicate any issues.
I know some browsers seem to ‘do their own thing’ with regards to certificates, rather than use the machines certificate store, but it seems that while Brave SEEMS to be looking at the machines certificate store, it’s not behaving that way.
The ONLY thing I can think of is the ‘subject’ in the certificate is not just the CN - it’s got E, CN, OU, O, L, S & C values all in a long comma separated string - but if that is the issue, shouldn’t IE not like it as well?
Every other browser dislikes the certificate. Yes, IE is on the same machine, and yes, as the machine is joined to the domain whose DC issued the certificate, the time is synced to the domain controllers. It is really odd, but I had a thought after poking around in the templates and I’m currently tinkering with the CA templates… perhaps the issue/solution lies there.
And the time on the DC is correct? Sorry, have to ask… have seen my share of network time problems traced back to bad DC time.
Anyway if other browsers reject it as well then maybe we can tie it to some kind of Chromium-specific behavior, unless Firefox does the same. If it’s Chromium-specific that gives us the advantage of being able to search for similar issues with Chrome where we’d likely find others with the same problem.
Welp… Scratch that. I was tinkering with the ADCS template and found the ‘Subject Name’ tab, but apparently, when you set it to ‘Build from this Active Directory Information’, it won’t appear on the web enrollment. I tried issuing a new cert with only the name in the form so the subject ONLY had the FQDN, but no difference. The fact is the cert issued by AD CS has specifically ‘CN = myFQDN’, which is apparently recognized by IE, and is the same format I see in other public CA issued certs, so I’m at a loss as to why nothing seems to like it. I’ll have to keep digging.
BTW, on the time, you and me both. Years ago all machines on my network were losing like 45 minutes a day, I was pulling my hair out trying to figure out why. Changed the time source from ‘time.windows.com’ to ‘time.nist.gov’ and problem solved. Lesson learned: always. Always. ALWAYS! set your time source to ANYTHING other than ‘time.windows.com’ if you want your time to stay correct.
Slight sidebar, this really is driving me nuts. I’m also having the same issue with the certificate on my android phone. But what’s REALLY nuts is my company has an Avaya IP Office phone system, and we have a session border controller that handles most of our phone traffic. This is all heavily reliant on certificates. The certificates for the phone system are self generated, which requires that the CA cert be installed on any device that will be interfacing with it. I have used the android and ios procedures to install the phone systems root ca cert, and everything, the browsers and the app, are all happy. Used the same exact procedure to install the root ca cert from my AD CS and it’s essentially ignored. But yet following the ios procedure on an ios 12.5.5 device, once the profile is installed and the cert was enabled under ‘certificate trust settings’, it’s happy as a clam. I’m at a loss.
I wonder if it might be worth running the cert thru a decoder like https://www.sslshopper.com/certificate-decoder.html , or locally use OpenSSL to do the same; make sure the naked, decoded result looks as expected.
One other thing I just thought of… ISTR MSIE being particular about only requesting ‘intranet’ traffic if you specified the FQDN, whereas other browsers would work. Could it be that your HTTP request is being translated into an FQDN on the wire, or maybe it’s an FQDN in the first place and in the other browsers it isn’t… lot of permutations here but I think you get where I’m going with this. In short, perhaps it’s not a matter of the name itself being “wrong” but just not matching against the request due to formatting (FQDN vs. hostname).
Easiest way to check might be to look in DevTools and make sure the actual outgoing network request matches the CN (or SAN) in the cert. Don’t recall if MSIE has a similar tool built-in to do the same though. Or you might be able to see sufficient detail in a packet capture on the client box.
Sorry, have to ask… have seen my share of network time problems traced back to bad DC time.