Bonjour, j'ai un problème pour configurer plusieurs certificats pour l'écouteur ALB. Voici un fragment de mon modèle CF:
DiscoveryListenerHTTPS: Type: AWS::ElasticLoadBalancingV2::Listener DependsOn: - DiscoveryLoadBalancer - DiscoveryLoadBalancerTargetGroup Properties: Certificates: - CertificateArn: !Ref CertificateArn1 - CertificateArn: !Ref CertificateArn2
et la réponse est:
Il est possible de spécifier jusqu'à «1» ARN de certificat, mais «2» a été spécifié (Service: AmazonElasticLoadBalancingV2; Code d'état: 400; Code d'erreur: TooManyCertificates; ID de demande: XXXXXXXXX)
p>
3 Réponses :
C'est un peu maladroit; le modèle CF pour la création de l'écouteur définit uniquement le certificat par défaut.
Vous devriez pouvoir ajouter des certificats supplémentaires à l'auditeur avec cet objet: https://docs.aws.amazon.com /AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-listenercertificate.html
Je suis venu ici à la recherche de la même réponse. J'ai trouvé que la réponse n'était pas clairement énoncée dans les commentaires / réponses, alors je vais le faire. Bien que vous puissiez spécifier plusieurs certificats SSL pour un écouteur HTTPS, vous n'êtes pas autorisé à spécifier plusieurs certificats sur la ressource d'écoute HTTPS directement dans le modèle CFN. Vous devez créer une autre ressource dans votre modèle pour des certificats supplémentaires comme celui-ci:
AdditionalListenerCertificates: Type: AWS::ElasticLoadBalancingV2::ListenerCertificate Properties: Certificates: - CertificateArn: !Join - ":" - - "arn:aws:acm" - !Ref AWS::Region - !Ref AWS::AccountId - !Join ["/", ["certificate", "<you-certificate-id>"]] ListenerArn: !Ref HTTPSListener
Une note - si vous créez le certificat dans le même modèle, utilisez simplement ! Ref
, sinon passez l'arn complet en paramètre. S'il vous plaît, pour l'amour de Dieu, ne construisez pas de chaînes avec ! Rejoignez
car il lit mal et casse encore pire.
Merci beaucoup pour ce commentaire! J'ai vu beaucoup d'exemples de modèles sur github qui construisent des chaînes en utilisant join, et j'ai pensé que c'était une pratique courante. Agréable d'entendre des points de vue opposés. Existe-t-il un guide des meilleures pratiques que vous pouvez recommander pour éviter ce genre de chose, ou cet exemple particulier vient-il simplement de l'expérience?
Par exemple, ! Sub "arn: aws: acm: $ {AWS :: Region}: $ {AWS :: AccountId} / certificate / $ { certificate_id}>"
, où certificate_id
passé en paramètre. Plus compact et (IMHO) lisible par rapport au double ! Rejoignez
. Je suggérerais également d'éviter de construire un certificat (et tout vraiment) arn
à la volée lorsque vous pouvez réellement passer tout le arn
en tant que paramètre - tout simplement trop d'effort. Il n'y a pas de meilleure pratique en soi, AFAIK, prenez-le plus comme une opinion.
Cela fonctionne pour moi, est un exemple d'écouteur par port 443 utilisant un certificat par défaut puis une liste de certificats avec au moins un certificat et associé à l'écouteur qui a été précédemment créé:
Listener443: DependsOn: - LoadBalancer Type: AWS::ElasticLoadBalancingV2::Listener Properties: Certificates: - CertificateArn: !Ref CertificateARN LoadBalancerArn: !Ref LoadBalancer DefaultActions: - Type: fixed-response FixedResponseConfig: ContentType: text/plain MessageBody: "Not Found" StatusCode: 404 Port: 443 Protocol: HTTPS CertificatesList: Type: AWS::ElasticLoadBalancingV2::ListenerCertificate Properties: Certificates: - CertificateArn: !Ref CertificateARN2 ListenerArn: !Ref Listener443
La documentation indique: Si vous spécifiez HTTPS ou TLS pour la propriété Protocol, vous devez spécifier exactement un certificat. Vous n'avez pas inclus de protocole dans votre modèle mais c'est un champ obligatoire, donc je ne sais pas pourquoi il n'est pas présent.