web-dev-qa-db-ja.com

SSLリスナーを追加できません。キーのサーバー証明書が見つかりません

GoDaddyから購入した証明書を使用して、ロードバランサーにSSLを設定しようとしています。

コンソールで証明書をアップロードしようとすると、エラーが発生しました

ロードバランサーの作成に失敗しました:次のキーのサーバー証明書が見つかりません:arn:aws:iam :: ************:server-certificate/mycert

SSL証明書を追加するときに、このエラーに遭遇したことがありません。 iamがここで使用されている理由がわかりません。

いくつかグーグルした後、aws cliを使用してiamに証明書をアップロードすることができました(ここでも、なぜこれを実行する必要があるのか​​わかりません)。

これで、リスナーを変更するときに、アップロードした証明書を既存のSSL証明書として確認できます。ただし、変更をロードバランサーに保存しようとすると、同じエラーが発生します。証明書が存在することを確認しました:

$ aws iam list-server-certificates
{
    "ServerCertificateMetadataList": [
        {
            "ServerCertificateId": "*********************", 
            "ServerCertificateName": "mycert", 
            "Expiration": "2018-11-19T18:47:38Z", 
            "Path": "/", 
            "Arn": "arn:aws:iam::************:server-certificate/mycert", 
            "UploadDate": "2015-11-19T19:23:32Z"
        }
    ]
}

(ここでは難読化されたアカウント番号がエラーと同じであることを確認しました)

ここから行き詰まっています。証明書をこのロードバランサーに適用できないのはなぜですか?


Edit Thu Nov 19 11:47:18 PST 2015

しばらく待ってログアウトしてからログインすると、SSL証明書でリスナーを更新できました。ただし、正常に動作していないようです。 HTTPSでドメインをロードしようとすると、リクエストがタイムアウトします。証明書を読み込めないようです

$ echo | openssl s_client -connect www.example.com:443 2>/dev/null | openssl x509 -noout -subject
unable to load certificate
69457:error:0906D06C:PEM routines:PEM_read_bio:no start line:/SourceCache/OpenSSL098/OpenSSL098-52.30.1/src/crypto/pem/pem_lib.c:648:Expecting: TRUSTED CERTIFICATE
20
Steve Robbins

ELBをWebコンソールから作成しようとすると、同じ問題に直面しました。 GUIを使用して新しい証明書のアップロードを作成しようとしていましたが、最終的に同じエラーで失敗しました。 aws cliを使用して証明書ファイルを個別にアップロードすることで解決しました。これはこのドキュメントで説明されています- http://docs.aws.Amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ssl-server-cert.html#upload-cert

このように証明書、秘密鍵、証明書チェーンをアップロードします

aws iam upload-server-certificate --server-certificate-name my-server-cert \
  --certificate-body file://my-certificate.pem --private-key file://my-private-key.pem \
  --certificate-chain file://my-certificate-chain.pem

次に、ウェブコンソールに移動し、[AWS Identity and Access Management(IAM)から既存の証明書を選択する]オプションを選択して、アップロードしたばかりの証明書ペアを選択します。その後は問題なく動作します。

32
suryasankar

エラーは誤解を招くものです。証明書をアップロードします。そのエラー終了を受け取ったら、変更に戻ります。既存のIAM証明書を選択し、ドロップダウンをクリックします。そこに新しい証明書が表示されます。

17
user384640

私は同じ問題を抱えていましたが、ありがたいことに、CLIを実行する必要なしに問題を解決することができました。 ELBにHTTPSリスナーを追加してもらいました証明書チェーン公開鍵証明書フィールドに貼り付け、証明書自体の後に。

このエラーは、証明書チェーンがコンソールの独自の証明書チェーン入力ボックスに貼り付けられたときにのみ現れました(オプションとしてマークされています)。 why違いは確かですが、ELBにHTTPSリスナーが作成され、すべて良好でした。

5
Matthew Long

証明書名の特殊文字が原因でした:私の場合は。(ドット)。証明書名からすべてのドットを削除した後、すべてがうまくいった

3
essis

私もこれを叩きました。新しいELBを作成するために5回試行しましたが、毎回失敗しました。 APIバリアントを試したことはありませんが、SSL証明書を

  1. 最初にELBを作成します。その後
  2. hTTPからHTTPSに変更し、証明書+キー+中間体をアップロードして、リスナーを変更します。
2
Ztyx

私はこれを回避するために、awsコンソールの証明書マネージャーに行き、最初にそこにアップロードしました。次に、ロードバランサーウィザードを使用して、アップロードした証明書を選択します。

1
user160004

私も同じ問題に直面しました。私の場合、SSL証明書をアップロードすると「キーのサーバー証明書が見つかりません」というエラーが表示されましたが、最終的にはアップロードされてドロップダウンに表示されます。 CLI経由でアップロードするときにエラーが発生しません。 AWSサポートに問い合わせたところ、以下のエラーの理由が表示されました

これが発生する理由は、結果の一貫性です。アップロードされた証明書はIAMに保存されます。 IAMには大規模なデータベースがあるため、アップロードされた証明書はすべてのデータベースに伝播する必要があります。伝播するのに十分な時間がない場合、この証明書をフェッチしようとしているELBは、照会しているエンドポイントでそれを見つけることができません。したがって、「キーのサーバー証明書が見つかりません」をスローします。最終的に伝播されると、後でアップロード済みの証明書として見ることができます

1
Ramadas

証明書を直接アップロードする場合も同じ問題がありました。

証明書マネージャー(AWS Certificate Manager – ACM)を使用した場合、証明書をアップロードできました。その後、ドロップダウンリストから証明書を選択するだけです。

0
flokoe

クラシックロードバランサーを作成する前に、AMI(本番環境のインスタンスのイメージ)を作成する必要があります。これで、ロードバランサーの作成の設定に移動し、プロセスを再度実行します。この後、証明書が提供され、私の場合はすべてうまくいきます。

0
dbarenas

notoptionalCertificate Chainフィールドに入力することで、これを回避しました。

0
Danny Schoemann

これと同じ問題があり、最終的に修正されたのは、ロードバランサーのセキュリティグループに入り、ポート443が開かれていることを確認することでした。

0
Chris DeGroat

AWSウェブインターフェースを使用するときの同じ問題:有効な証明書、正しいキー、および完全なチェーンをアップロードしましたが、上記のエラーが発生しました。

証明書を別の(テスト)ロードバランサーにアップロードしようとしました。アップロードは機能しましたが、リスナーのステータスは「無効な証明書」と表示されます。

「証明書の選択」ダイアログを再度開いたときに、証明書が選択されていませんでした。しかし、証明書リストで選択できるため、証明書が正しくアップロードされたことは明らかです。

それで、元のロードバランサーに戻って、このアップロードされた証明書を割り当てようとしましたが、奇妙なことに、リストにありませんでした。私はそれを再試行し、証明書とそのキーをアップロードしましたが、証明書チェーンは省略しました。これはうまくいったので、それはチェーンでなければならないことを知っていました、それは正しくありません(それは商品証明書です)。公式ページからチェーンを再度ダウンロードし、バンドル全体をアップロードしました。奇妙なことに、私は両方を比較したとき-破損したものと新しくダウンロードしたものを比較したとき、それらは同じように見えます。同じ日付、同じシリアル、同じです。しかし、違います。

要するに、中間証明書を再度ダウンロードすることで機能しました。

0
n.r.