ADCS 証明機関でSHA1からSHA2への移行で参考になる手順

ADCS 証明機関でSHA1からSHA2への移行で参考になる手順です。まだ、移行ができていない場合に使えると思います。

サーバー認証証明書：CAは、2016年1月1日以降、SHA-2アルゴリズムのみを使用して新しい証明書の発行を開始する必要があります。Windowsは、2017年1月1日以降、SHA-1で署名された証明書を信頼しなくなると説明があります。セキュリティの観点からも移行は重要です。

MicrosoftのSHA1非推奨計画は、Microsoft Trusted Root Certificateプログラムのメンバーが発行した証明書にのみ適用されます。内部PKI階層は引き続きSHA1を使用する場合があります。ただし、これはセキュリティリスクであり、SHA256にできるだけ早く移行するために注意を払う必要があるとあります。

2階層の構成の場合の手順です。

OFFLINE ROOT

オフラインルートとオンライン発行CAの両方のCAとプライベートキーをバックアップします。複数のCA証明書がある場合（複数回更新している場合）、それらすべてをバックアップする必要があります。

MMCを使用して秘密キーをバックアップするか、CERTSRV.mscを使用して、オンラインの下位発行CAとオフラインルートCAの両方で次のようにバックアップするCA名を右クリックします。

秘密鍵ファイルのパスワードを提供します。

手順1Cで示されているように、レジストリの場所をバックアップすることもできます。

ステップ2 – CAサービスを停止します

ステップ3 –このコマンドは、プロバイダーを決定するために以前に議論されました。

Certutil –store <自分のCA共通名>
上記のTechNet記事のステップ4とステップ6は、UIを使用して行う必要があります。

a。MMCを開きます-ローカルコンピューターの証明書スナップインを読み込みます

b。各CA証明書を右クリックします（複数ある場合）–エクスポート

c。はい、秘密鍵をエクスポートします

d。チェック–可能であれば、証明書パスにすべての証明書を含めます

e。チェック-エクスポートが成功した場合、秘密鍵を削除します

f。[次へ]をクリックして、エクスポートを続行します。

手順5
結果の.pfxファイルをWindows 8またはWindows Server 2012コンピューターにコピーします

Windows Server 2008（およびそれ以前）は必要なKSP変換コマンドをサポートしていないため、変換にはWindows Server 2012 certutil.exeが必要です。Windows Server 2012より前のADCSバージョンでCA証明書を変換する場合は、CAからCA証明書をエクスポートし、certutil.exeで-KSPオプションを使用してWindows Server 2012以降にインポートしてから、新しくエクスポートする必要があります署名された証明書をPFXファイルとして作成し、元のサーバーに再インポートします。

Windows 8またはWindows Server 2012コンピューターで手順5のコマンドを実行します。

Certutil –csp <KSP名> -importpfx <CA証明書/キーPFXファイル>

ステップ6

a。MMCを使用して前述したように、Windows 8またはWindows Server 2012コンピューターで実行します。

b。MMCを開きます-ローカルコンピューターの証明書スナップインを読み込みます

c。インポートしたばかりのCA証明書-すべてのタスク-エクスポートを右クリックします

*変換コマンドを実行し、MMCを介してエクスポートしようとすると、「はい、秘密鍵をエクスポートします」が淡色表示される問題を確認しました。この動作が発生した場合は、.PFXファイルを手動で再インポートし、インポート時にこのキーをエクスポート可能としてマークするボックスをオンにします。これは以前の変換には影響しません。

d。はい、秘密鍵をエクスポートします。

e。チェック–可能であれば、証明書パスにすべての証明書を含めます

f。チェック-エクスポートが成功した場合、秘密鍵を削除します

g。[次へ]をクリックして、エクスポートを続行します。

h。結果の.pfxファイルを宛先2008 R2 ROOTCAにコピーして戻します

ステップ7

再びUI（MMC）を使用して、.pfxをROOTCA上のコンピューターストアにインポートして戻すことができます。

*インポート中にこのキーをエクスポート可能としてマークすることを忘れないでください。

***重要***

上記の手順4および手順6で示したように最初のCA証明書をエクスポートした後、同じキーでCAを複数回更新した場合、以前に更新したCA証明書との秘密キーの関連付けが解除されます。これは、エクスポートが成功すると秘密鍵を削除するためです。変換を行って、結果の.pfxファイルをCAにインポートした後（秘密キーをエクスポート可能としてマークすることを忘れないでください）、以前に更新された追加のCA証明書ごとに、昇格されたコマンドプロンプトから次のコマンドを実行する必要があります：

certutil –repairstore MYシリアル番号

シリアル番号は、CA証明書の詳細タブにあります。これにより、公開証明書と秘密キーの関連付けが修復されます。

ステップ8 –

CSP.regファイルには、上部で強調表示されている情報が含まれている必要があります。

ステップ8c

ステップ8d – CSP.regを実行する

ステップ9

EncryptionCSP.regファイルには、上部で強調表示されている情報が含まれている必要があります。

ステップ9c –検証– certutil -v -getreg ca \ encryptioncsp \ EncryptionAlgorithm

ステップ9d – EncryptionCsp.regを実行します

ステップ10

CAハッシュアルゴリズムをSHA256に変更する

CAサービスを開始する

手順11

ルートCAの場合：ルートCAの移行を完了してからルートCAの証明書を更新するまで、CA証明書自体の移行は有効になりません。

オフラインルート証明書を更新する前に、次のようになります。

新しいまたは既存の（同じ）キーでCA自身の証明書を更新することは、証明書の残りの有効性に依存します。証明書の有効期間が50％に近い場合は、新しいキーで更新することをお勧めします。CA証明書の更新に関する追加情報については、以下を参照してください–

https://technet.microsoft.com/en-us/library/cc730605.aspx

新しいキーまたは同じキーでオフラインルート証明書を更新すると、以下のスクリーンショットに示すように、独自の証明書がSHA256署名で署名されます。

これで、オフラインルートCAはSHA256用に完全に構成されました。

CERTUTIL –CRLを実行すると、SHA256を使用して署名された新しいCRLファイルが生成されます

既定では、CRT、CRL、およびデルタCRLファイルは、CAの％SystemRoot％\ System32 \ CertSrv \ CertEnrollの場所に公開されます。CRLファイル名の形式は、CAの「サニタイズされた名前」に括弧で囲まれたCAの「キーID」（CA証明書が新しいキーで更新された場合）および.CRL拡張子です。CRL配布ポイントとCRLファイル名の詳細については、次を参照してください– https://technet.microsoft.com/en-us/library/cc782162%28v=ws.10%29.aspx

この新しい.CRLファイルをドメインに参加しているコンピューターにコピーし、管理者特権でコマンドプロンプトからエンタープライズ管理者としてログオンしてActive Directoryに公開します。

新しいSHA256 ROOT CA証明書についても同じことを行います。

certutil -f -dspublish <.CRTファイル> RootCA
certutil –f -dspublish <.CRLファイル>
次に、オンライン発行下位CAの移行を続けます。

手順1 – CAデータベースと秘密キーをバックアップします。

CAレジストリ設定をバックアップする

ステップ2 – CAサービスを停止します。

ステップ3 – CA証明書の詳細を取得する

Certutil- 「サブCA名」を保存します

画像

下位CA証明書を更新したことがないため、1つしかありません。

ステップ4 – 6

OFFLINE ROOTで以前に達成されたことからわかるように、手順4〜6はMMCを介して実行され、前述の理由によりWindows 8またはWindows 2012以降のコンピューターで変換を行う必要があります。