, a Scandiavian telecom company issuing certificates in the Nordic countries, has added a new Root to Opera's Root repository. Please note that the test site
is cross-signed by one of their older certificates, so it will work without certificate warnings, even without an update.Revocation trouble in Hungary
After we released the Opera 12.10 beta versions, we started receiving a number of reports about problems with some secure sites.
The early group of reports concerned problems with "Fatal Error (1578)" messages (a special code meaning "CRL verification failed", presumably due to a signature verification problem, resulting in a "Bad certificate", code 42, SSL/TLS error to the server) on some Hungarian secure sites. We quickly tracked the immediate cause of the problem down to new, stricter code in Opera's crypto library, OpenSSL
1.0.0. We upgraded to this version of OpenSSL in Opera 12.10.
We found that the Hungarian CA which issued the certificates, Netlock
(a CA that is not a member of Opera's Root repository at present), was distributing Certificate Revocation Lists (CRLs) that marked the "Revocation Reason" extension as "critical".
OpenSSL 1.0.0 made enforcement of Critical CRL extensions much more strict than it was previously, since the specification of CRLs is says that unhandled or not understood critical extensions
must result in a verification failure, because these extensions can change the meaning of the entry, which could introduce security problems if they are ignored.
While OpenSSL understands the "Revocation Reason" extension, it is defined as non-critical
, meaning that it must not be marked as critical, and OpenSSL therefore does not check for it when looking for the critical extensions it does handle. The result is that OpenSSL later discovers there are unhandled critical extensions in the CRL and correctly returns an error signaling that the CRL cannot be used, which also means the certificate cannot be trusted.
Netlock has been informed about the problem, and they are working to fix it. At present, we do not know how long that will take. We do expect that part of the fix will require that Netlock's Certificate Practice Statement document is updated, which might require some protracted formal steps before the CRL-generating profiles can be updated.Replacement of intermediate CA certificates
After the Opera 12.10 final was released, we started receiving other reports, about "Fatal Error (47)" (the SSL/TLS error code for "invalid parameter") errors on some sites, this time in France. Again, we tracked the immediate cause of this problem to stricter handling in OpenSSL 1.0.0.
It turned out that the certificates were issued by a French CA/hosting provider, TBS Internet
, using Subordinate CA certificates issued by Comodo
. When Comodo created those Subordinate CA certificates (in 2005), it made a mistake when coding a Certificate Policy identifier, adding an unnecessary byte in the middle of the identifier. This did not have any immediate consequences, but, in OpenSSL 1.0.0, a sanity check was added when decoding these identifiers, looking for this particular error, again for security reasons.
This sanity check was added because it was discovered that, if a CA did not decode these identifiers (as the two different binary representations would encode the same identifier), but relied on a binary check of the encoded identifiers (the binary compare would not match the incorrectly encoded identifier), an attacker could smuggle unverified information past the CA and into an issued certificate -- for example as a Common Name field, which can be used to check the hostname of the server, and thus be able to insert then name for a server the attacker did not own, thereby allowing a man-in-the-middle attack against that server. Since the same structure and code is used in both places, it is not possible to separate the reasons for the failure and ignore it (there might also be other reasons for the reported errors).
The only way to fix the problem is to reissue the CA certificates. One of the CA certificates was reissued in 2011 when the problem was originally discovered, but not the two others issued to this CA. Unfortunately, that was just the first step. After the updated CA certificate had been issued, all the sites using the certificate had to update their servers to present the new certificate. This did not happen. The TLS Prober recorded 234 sites with certificates from TBS in recent runs, and, of 191 sites that had certificates from the CA that had been given an updated certificate, 182 of the 184 that sent the intermediate CA certificate had *not* replaced the old certificate.
Considering that there are almost 2000 SSL/TLS certificates issued from all the three involved Subordinate CA certificates, this did not bode well for a quick update of the remaining 1900 servers that needed to be updated in order to fix the problem. Waiting for the sites to update did not seem to be practical, and, as the sanity check is a security mitigation measure disabling it was not an option; another, stronger measure was needed: patching the certificates themselves.
While we are reluctant to ship intermediate CA certificates in the repository, as it should not be necessary, we occasionally do when there are technical or practical reasons for doing so, such as when we replaced the old Verisign MD2 signed Certificates with SHA-1 signed certificates
in Opera 10.0, when some of the old intermediate CA certificates were too tied to the old Root certificate.
In this case, after Comodo last week reissued the other two SSL/TLS CA certificates, we are adding the three updated TBS intermediate CA certificates to the repository. The first time a site using certificates from one of these CA certificates is encountered, the replacement certificate will be automatically downloaded and installed in the repository. The downloaded certificate will then be used instead of the certificate presented by the server when verifying the certificate, avoiding the problem with the incorrectly encoded identifiers. If any of the the older intermediates are already present in the local certificate repository (e.g., because it was automatically downloaded from the CA if a server did not present it) they will be replaced immediately when the certificate repository index is downloaded in the next update.
Test sites (from bug reports): 1
As before, for the impatient ones, Menu > Help > Check for Updates can be used to trigger the refreshing of the repository index, before the above test cases can be used.