2014年9月5日に発表されたように、Chromiumブラウザーの開発者は、SHA-1ハッシュアルゴリズムをもはや好んではいません。 ブラウザのアドレスバーの外観は、サイトで何かが「間違っている」という証明書で「閉じられている」httpsサイトへの訪問者に明らかになります。 文字列の外観は時間の経過とともに変化し、多少スムーズに移行するための時間が与えられます。最終的に、SHA-1を使用した証明書は、安全であるとはみなされなくなります。
その結果、すべてのChromiumベースのブラウザ（Google Chromeを含む）はSHA-1をサポートしなくなります。 このGoogleのイニシアチブは、MozillaとMicrosoftによってサポートされました。 Chromeでは、バージョン39で「SHA-1との特別な関連性」が表示されるようになります。これは2014年11月末に待っています。
当社では、サービスWebインターフェイスで、SHA-1を使用して発行されたワイルドカード証明書を使用しました。 彼はそれをWebNames.ru（Ragtime LLCでもあります）から購入したので、同じ証明書を再発行する方法について質問しましたが、SHA-2ではRagtimeテクニカルサポートに頼りました。
答えは簡単でした。
残念ながら、そのような機会はありません。 これにより、新しい証明書をすでに注文しています。
「うわー、私たちは「なんとなく恥だ！」 彼らはすでに彼らの技術サポートで書いた-そして、見よ、私たちの問題はすべて迅速かつ無痛に解決された。
そこで、学んだことは次のとおりです。CSRをリロードし、GeoTrust Webサイトの証明書注文WebパネルでハッシュアルゴリズムとしてSHA-2を選択することにより、追加料金なしで証明書が再発行されます。 証明書の（再）発行は有料または無料であることが判明し、CSRのデータのみが決定します：既にクライアントによって注文された証明書のデータと一致する場合、支払いは請求されません。
そして今、コツ：Ragtimeが顧客に送信したCSRのデータは、クライアント自体からのデータにまったく似ていません。 以下に、Ragtimeが使用するフィールドと、GeoTrustを介してSHA-2で証明書を無料で再発行するために指定する必要があるものを示します。
Organization: Regtime Organizational unit: Regtime City/locality: Samara State/province: Samara Country: RU
（悪くないので、謙虚さを持っていますよね？）
合計で、このデータを使用して新しいCSRを作成します（もちろん、 共通名フィールドには、証明書を再発行するドメインの名前を含める必要があります）。
openssl req -new -newkey rsa:4096 -sha512 -nodes -keyout www-example-com.pem -out www-example-com.csr
GeoTrust Webサイトの「 Self Service Reissuance 」セクションでダウンロードし、必要なもの、 つまり新しい証明書を取得します。
結論として、技術サポートからの否定的な答えを信じる価値は常にありません（Webnamesは経験上、「いいえ」と答えることが多いので）、頭を向けて問題を直接解決することは価値があります。 落ち着いて！
PS出版の数日後、Regtimeの人が私に（ウェブ名のアカウントデータから私の連絡先メールアドレスに）出てきて、彼らがこの点で何らかの対策を講じたことを確認しました。 何も言わない：Habrが読んでいるもの-おそらく悪くない、どういうわけか問題を解決しようとすることも良いが、問題はTPに連絡しても開かれなかった（それどころか、TPはクライアントにTPの量を説明しようとしていたクライアントのニーズ）、そして実践的な介入の後-ここでは、会社の側に誇りを持つ理由はないと思います。 見てみましょう、来年の誰が証明書を取得するかについて考える時間はまだあります:)