- Newest
- Most votes
- Most comments
mTLS is configured on the Custom Domain level so you can decide that only some paths will require it and other will not. What you can do is create two APIs with two different domains, e.g., mtls.api.com and tls.api.com. The first will map to the API for all routes that require mTLS. The second will map to an API that does not require it.
Unfortunately this solution needs to work with a legacy system where ALL resource paths need to be off of the same domain ... having two separate domains (one with and one without mTLS) is not an option. Your comment suggests what I was already thinking ... that it is not going to be possible to do what I need to do with the API Gateway mTLS support.
Hello,
I recently came across a blog post within the Compute Blog, which addresses mutual Transport Layer Security (TLS) and how a customer's self-managed Kafka clusters can have a trust relationship established between AWS Lambda using a private certificate authority (CA), even using a Amazon Managed Streaming Kafka (MSK) certificate by default as the certificates are signed by Amazon Trust Services CAs.
Also, without knowing many more of the customer requirements and/or dependencies of the applications, proxy configuration(s) involved, or that may need to be involved yet,
You can activate any combination of authentication modes (mutual TLS, SASL SCRAM, or IAM access control) on new or existing clusters. This is useful if you are migrating to a new authentication mode or must run multiple authentication modes simultaneously. Lambda natively supports consuming messages from both self-managed Kafka and Amazon MSK through event source mapping.
Also, I just saw this related topic within another re:Post, if the solution necessitates API Gateway.
I hope this helps.
Gabriel
As there is apparently no solution to this problem I want to pick up this topic and describe how we configured such a scenario outside AWS. When enabling mTLS for example with a good old Apache webserver, there is an option called SSLVerifyClient which can be set to optional (see https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslverifyclient). The same can be achieved using Traefik (it is called clientAuthType: VerifyClientCertIfGiven there, see https://doc.traefik.io/traefik/https/tls/#client-authentication-mtls ). In both cases the TLS is terminated for both sides (hence mutual TLS), but the client certificate is not required. All the certificate validation is done by the Webserver/Proxy/LoadBalancer. The application only has to check specific HTTP headers (e.g. headers["SSL_CLIENT_VERIFY"] == "SUCCESS" for apache), that tell whether a valid client certificate was provided.
We already investigated in activating mTLS in the ALB, but the ALB only has two modes: passthrough and verify, see https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_elasticloadbalancingv2.MutualAuthenticationMode.html
verify would require a client certificate for the whole domain. And passthrough simply disables the client certificate validation at TLS termination. The only option (other than using two domains) is hence to do custom client certificate validation inside our application (outside of TLS!), based on the information passed via the HTTP header X-Amzn-Mtls-Clientcert (see e.g. https://aws.amazon.com/de/blogs/networking-and-content-delivery/introducing-mtls-for-application-load-balancer/).
From the above answers I read, that also with API Gateway there is no such feature available, correct?
Relevant content
- asked 2 years ago
- asked 3 years ago
- asked 3 years ago
Hello TAW, Did you find any feasible solution to this scenario?
I was able to accomplish this by creating two load balancers. The Primary ALB (https://mydomain/) does not enforce mTLS, but has a rule on the listener with a condition that if the string '/pathA' is matched in the path, it does a 302 redirect to the mTLS only ALB where we require a valid client certificate ( https://mtls.mydomain:443/#{path}?#{query} ) I would prefer to achieve this without having to use an additional subdomain but on the back end I just had to add hostname support to the existing origin, as long as you can't bypass the ALB then the mTLS will be enforced.
I hope this helps,