Hi,
a late update on the certificate change:
We successfully switched to the new certificate Thursday 12 February.
We had one additional report from a user with a certificate issue after that change, but have not heard anything from any other users. We have therefore concluded that this problem was limited in scope.
The fix for the affected users was to delete the incorrect intermediate certificate from their local keychain.
Best regards, Olav Morken UNINETT / Feide
On Tue, Feb 10, 2015 at 13:06:50 +0100, Olav Morken wrote:
On Wed, Jan 28, 2015 at 15:02:20 +0100, Olav Morken wrote:
Hi,
our backup system was already upgraded to the new SSL certificates, so when we switched to the backup system we got at test of the certificates.
We got two reports from people where the browsers gave a certificate error using the new certificate. It looks like the computers for the ones affected had an extra intermediate certificate installed which matched the root certificate of our new certificates (AddTrust External CA Root). This caused the browsers to attempt to build a certificate chain using the intermediate certificate and then display a certificate error.
Until we have determined how widespread this problem is, we are postponing the certificate change.
Hi,
after investigating this, we have decided to proceed with the certificate change on Thursday 12 February, at 14:00. We haven't found any solutions to the certificate problem at our end, and have decided that those who are affected will have to make changes to their computer in order to solve the problem.
Investigations also revealed that this problem isn't specific to Feide, but that the affected systems also get the error accessing other sites with similar extended validation certificates, e.g.:
https://idporten.difi.no/ https://www.norid.no/
A bit more about the cause of the certificate error:
We have investigated the certificate problem, and tried various solutions for it, unfortunately without success.
It looks like the problem is caused by the client previously having installed / accepted an intermediate certificate "AddTrust External CA Root" issued by "UTN DATACorp SGC". "AddTrust External CA Root" is also a valid root certificate, which is installed by default on all major platforms.
The client computers (which were running Mac OS X 10.9.5) then failed to build a valid extended validation certificate chain, instead building one with the intermediate certificate. To avoid this, we tried to include the proper root certificate in the certificate chain we send from our web servers, but that did not help.
COMODO also supplied us with a certificate with an alternative chain (it used different intermediate certificates, but the same root certificate), but the problem was still present.
For some reason the clients do not get the error if the site isn't using an extended validation certificate. When testing with sites who use "AddTrust External CA root" but no extended validation certificate, no error occurs.
COMODO have not heard about this problem from any other customers, so it is unlikely that this problem affects a large number of users. We have therefore decided to proceed with the certificate installation.
Best regards, Olav Morken UNINETT / Feide