2回答
- 新しい順
- 投票が多い順
- コメントが多い順
2
The most probable reason is that you changed the SSLPolicy directly on the ALB instead of making the change via the SSLPolicy in your EB configuration (which in that case would be considered "drift" and get reverted by EB). If that's not the case, validate that you indeed changed the correct HTTPS listener and that your site isn't behind CloudFront or another CDN and that your scan isn't hitting the CDN's TLS configuration instead of the ALB's.
0
TLS13-1-2-Res-PQ-2025-09 supports both TLSv1.2 and TLSv1.3. Can you try with a TLS v1.3 only security policy like ELBSecurityPolicy-TLS13-1-3-2021-06.
Ref: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html
Thank you; that did not even occur to me. You're almost certainly right; I just went straight to the load balancer. It's getting a bit late, though, so forgive me if I wait until tomorrow to investigate further.
I can't find anything for the load balancer in the Beanstalk configuration (unfortunately, I'm not the Beanstalk expert around here). Can somebody please tell me which haystack my needle is in?
I just found out one place where I'd really screwed up: there were two load balancers, for two different applications ("C" and "W"), and I'd changed the one for "C," thinking it was "W," and then did the SSLLabs scan on W. When I scanned "C," it was rejecting TLSv1.1 and accepting TLSv1.3, and when I made the change to "W," still at the load balancer level, and scanned it, the same.
And I also found where the load balancer settings are in the Beanstalk configuration, and made the same change there.