Chromium: net::ERR_CERT_INVALID #2051
Comments
|
I'm at a friends place atm and have only kinda half read this but from what I'm able to gather by kinda skimming through this the following links seems applicable: https://security.stackexchange.com/a/110412/15922 I'll try to review this post and those two links in more detail as time permits. Got a busy next few days. |
|
Hi terrafrost, In the last few days I made some researches about this behavior and I found a bug from chromium: https://issues.chromium.org/issues/349054817 (In this bug an user writes something about an declined certificate using NULL in the signature algorithms and someone from chrome quote a paragraph from RFC 5758, this sounds like my previously described problem :D ) I took a look into RFC 5758 section 3.2: As far as i understand, we have to not set the parameters for the signature algorithm if one of the ecdsa algorithm identifiers is used. The parameters for the public key algorithm are not affected. I really appreciate all the hard work you’re putting into this project - it’s awesome. If there’s anything else you need from me or something I can help with, just let me know. Happy to pitch in. Thanks again! Best regards |
|
Apologies for the delay - between the US holiday of Thanksgiving and other support tickets it's been challenging to find the time to look into everything. Anyway, does this commit fix the issue for you?: Here's the branch: https://github.com./terrafrost/phpseclib/tree/2051-3.0 If so lmk and I'll merge that into the 3.0 branch. Thanks! |
|
Hi, Thank you so much! |
|
I'll get this merged into the 3.0 branch in the next few days! I want to add a unit test. Also, altho it's not as big of an issue in the 1.0 / 2.0 branches since they only support RSA, the fact that they also support PSS, which uses different OIDs, means that it'd be good to have this fix in those branches, too. Anyway, like I said, hopefully in the next few days (got a busy next few days ahead of me). Thanks for confirming that the code change worked!! |
|
This has been merged into the 3.0 / master branches: In-so-far as my 1.0 / 2.0 comments are concerned... 1.0 / 2.0 work completely differently from 3.0 / master (3.0+ determines the algorithm type from the key object you passed to it whereas 1.0 / 2.0 don't) so a proper code change would look very different. No need to hold up the 3.0 branch for the 1.0 / 2.0 branches. |
|
Hi, |
Hi,
im using phpseclib for issuing self signed certificates for my local systems.
The Problem
Since some days i have noticed some problems using chromium based browsers with only one of my websites. (Firefox works as expected on this site.) If i open this site on chromium based browsers, i got the error message: net::ERR_CERT_INVALID. This specific certificate was issued by an ECC Certificate Authority and used and RSA 2048 bit key.
Detailed Analyse of the Problem
For the further analysis it is important to know something about my local setup. For Web-Certificates i issued an intermediate CA by one of my root certificate authorities. The keytype of both authorities is ecc. I use rarely chrome based browsers since i switched to firefox on all my devices. The device/system where i use this certificate only supports RSA certificates.
I started my investigation with reading the changelog of chromium, but unfortunatelly i haven't found an acceptable answer or change which describes this behaviour. (Maybe someone other knows sth about it?)
Next i took a closer look to the certificate and have found one big differnence to a working one (issued from the same intermediate CA): ECC (works like a charm) vs RSA (does not work).
So the chain for the working certificate:
Root CA (ECC) -> Intermediate CA (ECC) -> working.site.example.com (ECC)
And the Chain for the not working certificate:
Root CA (ECC) -> Intermediate CA (ECC) -> error.site.example.com (RSA)
And therefor the "Public Key Algorithm" differences for the two certificates: "rsaEncryption" vs. "id-ecPublicKey"
So I used my test instance too reproduce this specific behaviour:
I created one Root Certificate Authority:
And I issued one Intermediate Certificate Authority and setup this as them in my production PKI:
Then i issued two Subscribe Certificates:
One with key type RSA (Lets call this one "Test Certificate RSA"):
And one with key type ECC (Lets call this one "Test Certificate ECC"):
Since this is only a fresh testing certificate authority and is not in production use, i leak the two private keys (and for better reproducing this behaviour ;) ):
"Test Certificate RSA":
"Test Certificate ECC":
Furthermore i installed a debian virtual machine and imported in chromium (Version 130.0.6723.116) the previously created root certificate authority. I installed nginx for checking if my subscriber certificates are working.
Our "Test Certificate ECC" works as expected on this setup (Lock-Symbol is not RED):
Compared too our "Test Certificate RSA" which does not work (Lock-Symbol is RED):
=> so we are able to reproduce this specific behaviour. All extensions on both Test Certificates are identical so we can previously exclude this as an reason.
Next I linted both certificates using x509lint:
"Test Certificate RSA":
"Test Certificate ECC":
It seems like my application is not setting Subject->Country in the correct encoding, but we can exclude every message which occours on both certificates, so only one leaves on the "Test Certificate RSA":
E: Algorithm parameter present.If we take a closer look into the ASN.1 structure of the "Test Certificate RSA", we can explore this (
$ openssl asn1parse -in file.crt):Combined to the previous x509lint message, we have to take a closer look at this lines:
It seems like, phpseclib sets the the parameter to
null. If i take a closer look into the code, i am able to find the following invendor/phpseclib/phpseclib/phpseclib/File/X509.php#505:If the algorithm is
rsaEncryptionphpseclib is setting the parameters tonull. (IF-Statement lines 522-525)For testing purposes i commented this if-statement out and created an new certificate (lets call this one "Test Certificate RSA Working"):
the private key of "Test Certificate RSA Working":
output of x509lint:
output of asn1parse:
As we can see, the parameters are not set anymore and x509lint does not display the error message
E: Algorithm parameter presentusing "Test Certificate RSA Working".I changed my nginx config and chromium displays the page using the new generated certificate:
maybe possible solution
It looks like chromium does not accept this parameters in the certificate if the signature is done using ecdsa. In my opinion an option is to switch the IF-Statement to check against the signature algorithm not against the used key type. (Since this is a very critical code part, I recommend to check this twice!)
Conclusion
I hope it's not a problem if the analysis part got a bit lengthy. If more information is needed, please let me know. I will try to provide it as quickly as possible.
Thank you for your time and consideration regarding this issue. I look forward to any feedback or assistance you may provide.
Best regards
Tobias
The text was updated successfully, but these errors were encountered: