3

The Problem

SSL certificate providers are moving from certificates signed with 1024–bit RSA keys to the new 2048-bit RSA key standard. One article explaining the background and significance of the issues this can cause; also an article from VeriSign about the migration.

For our particular web application, we have hundreds of customer systems who connect to our system via SOAP API calls over HTTPS and via HTTPS POSTs. A secondary issue is end users who browse to the HTTPS URLs. For end users, the upgrade from a VeriSign 1024-bit cert to a new 2048-bit cert should not have a massive impact as most browsers/operating systems will trust the new root CA. The legacy systems that connect to us are a different story, developed up to 10 years ago they are on a variety of hardware and OS flavours and have varying certificate management strategies. The impact if they don't trust the new root CA is catastrophic, as their systems that have been running with no problems for years will suddenly stop working. The fix is simple, but requires an administrator to apply on their server.

Potential Solutions

  1. Delay the upgrade for as long as possible (Tricky as the certs will expire in the next year and no reputable providers issue 1024-bit certs.)
  2. Contact each customer and walk them through the upgrade process (Possible but difficult as the technical contact that did the original implementation may no longer be around)

How are other organisations handling this problem?

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
JonathanJ
  • 83
  • 1
  • 6
  • 2
    Technical there is no constrain between the key length of the CA key and the key length of your server key. It is possible to sign a new longer server key with the already trusted CA key. Maybe you can ask your certificate provider to do that. – ceving Sep 14 '11 at 09:52
  • 1
    Note that even if you get your CA to sign your certificate with a 1024-bit key one more time that that is not a permanent solution, as it'll almost certainly not happen again when that certificate expires. The only long-term solution is to contact your customers and tell them to update their OS/your application. Also I'd recommend using the OS cert store instead of your own, since that will prevent things like this in the future as long as the customer keeps their OS updated. – dtech Sep 14 '11 at 10:21
  • Thank you for the suggestions - those tactics do let us delay the cutover time, however dtech pointed out it is not a permanent solution - I think you might have missed the point that it is not our trust store that is the issue, it is the trust store of each of the servers that connect to us. They trust the 1024-bit root CA from VeriSign but potentially don't know about the new 2048-bit root, when we did a smaller version of this upgrade around 25% of servers that connected to us didn't have the new root in place. – JonathanJ Sep 14 '11 at 23:52

3 Answers3

3

One of the features of the Certificate Authority system is that things change. Roots expire, new roots come into existence, certificates are revoked, roots go bankrupt after compromises. An update mechanism really needs to be in place to handle these changes.

There is a third option available, and that is to use a different CA that offers 2K certificates signed with an authority that was around 10 years ago. That isn't Verisign, but may be someone like Thawte.

If that proves unworkable, you'll need to go with a blend solution. Provide a test site with the new CA you picked for clients to validate against, and offer plenty of notice that the certificate will change and will break up to 25% of clients. Build as much update documentation as you can think of, and build more as clients run into issues. Stress that updating CA information is something that all systems need to do once in a while, so documenting this is a good thing in the long run; it's a best-practice.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • Good suggestions, thank you - we have updated our test site with the new CA which is identifying some customers with issues and have come up with a standard blurb explaining what is happening and what they need to do, I guess you always hope for a technical solution but it seems like it's all about communication. – JonathanJ Sep 22 '11 at 23:21
2

You need an option 2+1. You need to set up a test/alternate site with a new certificate for people to qualify against. They'll never know if they have your particular root without a bunch of work but it is likely that just about any person in their data handling group can test a new link for issues.

Give people a timeline until the new certificate has to be in place due to the hard renewal date and offer help as you suggested. Warn them that help will be limited in the last weeks since you don't have 1000 people just sitting around hoping they get to work this week. ;-)

Without a hard date people won't move on it and without an easy test most won't bother testing to see if they are effected by the change.

If you can get the alternate site working as production you can just transition people there permanently and know from your logs on the old server how many clients are still out of compliance.

Mark
  • 2,248
  • 12
  • 15
0

As you said, there are 2 options.

I would prepapre for option 2 and announce this change to your customer early combined with your technical assistance...

in case you know the ips of your customers' legacy systems, you could do some tricks, that will help you migrating on a customer-by-customer basis instead of doing a hard change on day X for everybody.

JMW
  • 1,451
  • 4
  • 19
  • 27