Hi,
the Feide IdP certificate expire Friday 20 February, so we have ordered and received new certificates. The new certificates will be installed Thursdag 22 January at 14:00.
The largest change with the new certificates is that they are signed using SHA-2 signatures. This should be supported by all major browsers, so we do not expect any problems with that change.
Best regards, Olav Morken UNINETT / Feide
On Fri, Jan 16, 2015 at 15:14:33 +0100, Olav Morken wrote:
Hi,
the Feide IdP certificate expire Friday 20 February, so we have ordered and received new certificates. The new certificates will be installed Thursdag 22 January at 14:00.
The largest change with the new certificates is that they are signed using SHA-2 signatures. This should be supported by all major browsers, so we do not expect any problems with that change.
Hi,
due to a scheduling error we have to postpone this certificate change. We will get back with a new date and time for the certificate change later.
Best regards, Olav Morken UNINETT / Feide
On Thu, Jan 22, 2015 at 13:32:47 +0100, Olav Morken wrote:
On Fri, Jan 16, 2015 at 15:14:33 +0100, Olav Morken wrote:
Hi,
the Feide IdP certificate expire Friday 20 February, so we have ordered and received new certificates. The new certificates will be installed Thursdag 22 January at 14:00.
The largest change with the new certificates is that they are signed using SHA-2 signatures. This should be supported by all major browsers, so we do not expect any problems with that change.
Hi,
due to a scheduling error we have to postpone this certificate change. We will get back with a new date and time for the certificate change later.
Hi,
this certificate change has been rescheduled for Thursday 29 January at 14:00.
Best regards, Olav Morken UNINETT / Feide
On Fri, Jan 23, 2015 at 12:27:52 +0100, Olav Morken wrote:
On Thu, Jan 22, 2015 at 13:32:47 +0100, Olav Morken wrote:
On Fri, Jan 16, 2015 at 15:14:33 +0100, Olav Morken wrote:
Hi,
the Feide IdP certificate expire Friday 20 February, so we have ordered and received new certificates. The new certificates will be installed Thursdag 22 January at 14:00.
The largest change with the new certificates is that they are signed using SHA-2 signatures. This should be supported by all major browsers, so we do not expect any problems with that change.
Hi,
due to a scheduling error we have to postpone this certificate change. We will get back with a new date and time for the certificate change later.
Hi,
this certificate change has been rescheduled for Thursday 29 January at 14:00.
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.
Best regards, Olav Morken UNINETT / Feide
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
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
-
Olav Morken