Поставщики сертификатов SSL переходят от сертификатов, подписанных 1024-битными ключами RSA, к новому стандарту 2048-битных ключей RSA. Одна статья, объясняющая предысторию и значение проблем, которые это может вызвать; также статья из VeriSign по поводу миграции.
Для нашего конкретного веб-приложения у нас есть сотни клиентских систем, которые подключаются к нашей системе через вызовы SOAP API через HTTPS и через HTTPS POST. Вторичная проблема - это конечные пользователи, которые переходят по URL-адресам HTTPS. Для конечных пользователей обновление 1024-битного сертификата VeriSign до нового 2048-битного сертификата не должно иметь серьезных последствий, поскольку большинство браузеров / операционных систем будут доверять новому корневому ЦС. Унаследованные системы, которые подключаются к нам, - это совсем другая история, они были разработаны около 10 лет назад, они основаны на разнообразном оборудовании и ОС и имеют различные стратегии управления сертификатами. Если они не доверяют новому корневому ЦС, последствия будут катастрофическими, поскольку их системы, которые работали без проблем в течение многих лет, внезапно перестанут работать. Исправление простое, но требует, чтобы администратор применил его на своем сервере.
Как другие организации решают эту проблему?
Одна из особенностей системы центра сертификации - все меняется. Корни истекают, появляются новые корни, сертификаты отзываются, корни банкротятся после компромиссов. Для обработки этих изменений действительно необходим механизм обновления.
Доступен третий вариант - использовать разные ЦС, предлагающий 2К сертификатов, подписанных органом, который был около 10 лет назад. Это не Verisign, но может быть кто-то вроде Thawte.
Если это окажется неработоспособным, вам нужно будет использовать раствор для смешивания. Предоставьте тестовый сайт с новым ЦС, который вы выбрали для проверки клиентов, и предложите много Извещаем, что сертификат изменится и сломает до 25% клиентов. Создайте столько документации по обновлениям, сколько сможете придумать, и создавайте больше по мере того, как клиенты сталкиваются с проблемами. Подчеркните, что обновление информации ЦС - это то, что все системы должны делать время от времени, поэтому в долгосрочной перспективе это хорошо документировать; это лучшая практика.
Вам нужен вариант 2 + 1. Вам необходимо создать тестовый / альтернативный сайт с новым сертификатом, чтобы люди могли претендовать на него. Они никогда не узнают, есть ли у них ваш конкретный корень, без кучи работы, но вполне вероятно, что практически любой человек в их группе обработки данных сможет проверить новую ссылку на наличие проблем.
Дайте людям график, пока не появится новый сертификат из-за жесткой даты продления, и предложите помощь, как вы предложили. Предупредите их, что помощь будет ограничена в последние недели, поскольку у вас нет 1000 человек, просто сидящих без дела в надежде, что они приступят к работе на этой неделе. ;-)
Без твердого свидания люди не перейдут к нему, а без простого теста большинство не будет беспокоиться о тестировании, чтобы увидеть, повлияло ли на них изменение.
Если вы можете заставить альтернативный сайт работать как производственный, вы можете просто перевести людей туда навсегда и узнать из своих журналов на старом сервере, сколько клиентов все еще не соответствуют требованиям.
Как вы сказали, есть 2 варианта.
Я бы подготовился к варианту 2 и заранее объявил об этом изменении вашему клиенту вместе с вашей технической поддержкой ...
Если вы знаете IP-адреса унаследованных систем своих клиентов, вы можете проделать несколько уловок, которые помогут вам переходить от одного клиента к другому вместо того, чтобы делать серьезные изменения в день X для всех.