web-dev-qa-db-ja.com

LetsEncryptで公開キーピンを使用できますか？

LetsEncrypt証明書を30日ごとに更新するようにcronjobを設定するときに、公開キーピンを設定できますか？

証明書が更新されると、公開キーピンも更新されますか？

sslssl-certificatetlshttp-headerspublic-key
10
Bob Ortiz

最初に注意すべきいくつかの言葉：

  • HPKPの実装を計画している場合は、何をしているのかを把握してください。
  • あなたがそれを正しく行わない場合、または「悪いことが起こった場合」、それらはあなたの制御下にない場合、あなたのドメインを使用不可能にするかもしれません。
  • それほど重要ではないドメイン、またはたとえば10秒などの非常に短いキャッシュ時間で設定をテストしてください。
  • 固定したい証明書について考えてください：ルート、中間、リーフ...
  • 別の（バックアップ）認証局を固定することが理にかなっている場合、それは中間証明書とリーフ証明書です。
  • 申し訳ありませんが、より安全です。別のバックアップCA /証明書を2つ用意しておくことが理にかなっている場合を考えてください。
  • これらのポイントや質問が「新しい」と聞こえる場合：HPKPの概要と一般的なトラップと警告を読んでくださいbeforeこれを実装します。

LetsEncryptで公開キーピンを使用できますか？

  • はい。

証明書が更新されると、公開キーピンも更新されますか？

  • これは、参照している証明書とピン留めしている証明書によって異なります。
12
gf_

Gf_が言ったすべてをエコーし​​ます。

しかし、質問に答えるために、はい、できます。

デフォルトでは、Let's Encryptは更新時に鍵と証明書を再作成します。これにより、リーフでピン留めしたい場合にHPKPの実装が困難になります。これはおそらく、中間の変更の場合に行う必要があります（ 2016年3月に行われたように ）。

HPKPを実行したい場合は、このためのいくつかのオプションがあります。

  1. リーフキーが変更されないように毎回CSRを作成する標準クライアントではなく、独自の固定CSRを使用します。 このブログの投稿 作成者がHPKPを使用しているため、これを具体的に行う方法を説明しています。
  2. 短いHPKP有効期限を使用し、その有効期限内に更新して、実際に証明書を変更する前に古いキーと新しいキーの両方を持つようにポリシーを変更します。
  3. リーフや証明書ではなく、Let's Encryptルートを固定します。
9
Barry Pollard

私はこれを dehydrated クライアントを使用してdns01検証で実装しました。 DNSがAzureでホストされているため、dns01フックは certzure です。

編集：私が秘密鍵について話すとき、明らかに私は常にあなたが公開鍵の部分だけをピンに変えることを常に意味します。名前が示すように、秘密キーはalwaysを非公開のままにする必要があります。実装の詳細については、自分のフックを参照してください。

これを可能にするには、秘密鍵のロールオーバーが必要です。つまり、現在の秘密鍵（Aと呼びます）とfuture秘密鍵（Bと呼びます）は常に手元にあるので、両方をピンに追加します。したがって、この時点でピンはAとBです。証明書の更新の日になると、秘密鍵Aは廃止され、Bが有効になります。同時に、新しい将来の秘密キーを取得し、それをCと呼びます。ピンリストを再生成して、BとCを含めます。これで、秘密キーをロールオーバーできます。脱水 これを今サポート 。

また、証明書を更新して秘密鍵をロールオーバーするたびに呼び出されるフックが必要です。私はこれを実装しました 自分で 。

最後に、私がこれを正しく行う場合は、次のことを確認する必要があります。

HPKP age x 2 < days between cert renewals

たとえば、HPKPの年齢が50日で、証明書を30日ごとに更新した場合、1日目にサイトにアクセスしたクライアントは秘密鍵AとBでスタックし、31日目にBとCにロールオーバーします。サーバーにはBとCがあり、クライアントにはAとBがあります。50日目でも一致し、クライアントはサイトを正しく開きます。

しかし、HPKPの年齢が70日かどうかを確認しましょう。 30日ごとに証明書を更新し、クライアントは1日目にサイトにアクセスしたため、秘密鍵AとBしかありません。31日目にBとCにロールオーバーし、61日目にCとDにロールオーバーしました。サーバーにはCとDがあり、クライアントにはAとBがあり、一致はなく、クライアントには、61日目から71日目までのHPKPポリシーが期限切れになるまで中指が与えられます。

別の、おそらくより安全な、そして確かにはるかに単純なオプションは、毎回同じ秘密鍵を使用し、1つまたは複数のバックアップ秘密鍵を生成し、それらをHPKP構成にハードコーディングして実行することです。

ええ、それはトリッキーであり、私が考えていなかった警告があるかもしれませんが、長期的に見ていきます。明らかに私はそれを短い（15日）HPKP年齢の重要でないサブドメインに展開したので、大きなトラブルを引き起こしません。

編集：Let's Encryptを使用してHPKPを設定し、Nginxを使用して脱水するのに役立つスクリプトをいくつか書きました：

HPKPinx

5
bviktor