I'm trying to connect to an MSK cluster using a Route 53 DNS CNAME record that points to the DNS record that is provided by Amazon.
AWS MSK DNS: b-1.msksandbox.nrfnuy.c42.kafka.us-east-1.amazonaws.com
DNS I need to use: b-1.msk.sandbox.internal.company.com
The error I get:
Error while executing topic command : SSL handshake failed
ERROR org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching b-1.msk.sandbox.internal.company.com found.
Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching b-1.msk.sandbox.internal.company.com found.
When I look at the server cert it says
Server certificate
subject=CN = *.msksandbox.nrfnuy.c42.kafka.us-east-1.amazonaws.com
issuer=C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
I wonder if it's possible to make Route 53 and MSK work together (I'm using IAM authentication)
You can implement this with NLB.
Then you will attach you certificate on NLB. Your certificate will terminated on NLB. Connection between NLB and MSK will use MSK certificate.
Custom domain names aren't supported currently.
In order to implement custom domain names using R53 and certificates, you will need to terminate certificates at NLB, and then target group will create a connection to the........ IP address of a broker, because in target group all you can specify is IP, not brokers' domain name. SSL connection will fail between NLB and a broker, because IP address of a broker is not added to a certificate deployed on a broker side, so NLB won't trust that connection.
The only way it may work is if you use PLAINTEXT connection (port 9092) between NLB and MSK. But this is not secure and not recommended approach.
Related
I'm trying to update the certificate of the Load balancer in GKE from Google-managed to self-managed.
I was following up on this docs to create Google-managed certificates, but I didn't find any docs for creating self-managed certificates. I am not sure how to do this. I would appreciate it if someone could tell me what should I do?
Self-managed SSL certificates are certificates that you obtain, provision, and renew yourself. You can use this resource to secure communication between clients and your load balancer.
Make sure that you have the domain names that you want to use for your self-managed SSL certificate. If you're using Google Domains, see Step 1: Register a domain name using Google Domains.
Step 1: Create a private key and certificate
Step 2: Create a self-managed SSL certificate resource
Step 3: Associate an SSL certificate with a target proxy
Step 4: Update the DNS A and AAAA records to point to the load balancer's IP
address
Step 5: Test with OpenSSL
After the certificate and domain statuses are active, it can take up to 30 minutes for your load balancer to begin using your self-managed SSL certificate.
For detailed information follow Use self-managed SSL certificates.
I'm having some mongodb connection securtity concerns for my env.
Here is my environment:
one ECS hosted on cloud that has a public IP but no domain and no ssl certificate neither.
installed mongodb service on this ECS that needs username/password to authenticate
only specific IPs in the whitelist can access the ECS/mongodb
I'm wondering if the data transfer between this mongodb and my local pc is safe or not?
Will the data be encrpyted during the transmission or just plain text so that everyone on the internet can catch and read it? (As I don't have https so it's not using TLS/SSL)
Can canyone explain the machanism or give some some doc links?
Thanks!
As your not using SSL, your data on fly is not encrypted. You need to use TLS/SSL to encrypt the network transmission. You must have the TLS/SSL certificates as PEM files, which are concatenated certificate containers
In addition to encrypting connections, TLS/SSL allows for authentication using certificates, both for client authentication and for internal authentication of members of replica sets and sharded clusters
So I currently have a self-managed certificate, but I want to switch to a google-managed certificate. The google docs for it say to keep the old certificate active while the new one is provisioned. When I try to create a google-managed certificate for the same ingress IP, I get the following error: Invalid value for field 'resource.IPAddress': 'xx.xxx.xx.xx'. Specified IP address is in-use and would result in a conflict.
How can I keep the old certificate active, like it tells me to, if it won't let me start provisioning a certificate for the same ingress?
This can happen if 2 load balancers are sharing the same IP address (source). most likely you would have to detach that IP - or add another IP and then swap, once the certificate had been provisioned. it's difficult to tell by the error message, while not knowing which command had been issued.
I want to proxy API Gateway requests to a container in an ECS cluster. As API Gateway can not be placed in a security group, I have to expose the service through an internet-facing ALB load balancer. To verify that the service only handles traffic from API GW, I'm looking to use client certificates.
Is there a way to have ELB verify the API Gateway client certificate for me and terminate the SSL connection before handing the request off to my HTTP backend?
If ELB cannot verify the certificate, it seems to me that I have to "downgrade" the proxy to a TCP proxy, and perform the SSL handshake in my service. However, to do this, I also need to serve the certificate from the service. This is a problem because I'm using AWS provisioned SSL certificates, and I do not possess the private key. Thus I would have to not only recreate the SSL handshake, but also get my SSL certificate from somewhere else, is this correct?
Hoping there's a low-effort way to set up the trust between API Gateway and an ECS service behind an ALB.
Unfortunately, ELB does not support validating the client certificate for you. You can implement SSL termination on your service and use the ELB in TCP mode (or use the newer NLB). You don't need the private key of the client certificate, you simply add the public key/cert to your trusted CA on the service so that the service only trusts the API GW client certificate.
I am trying to consume a HTTPS based SOAP WebService via ColdFusion, but it is returning "Connection Failure".
On dumping the result variable, it showed:
Error Detail: "I/O Exception: Name in certificate 'subdomain1.domain.com' does not match host name 'subdomain2.domain.com'"
I can ignore such warning if I browse the HTTPS wsdl in browser, But the Question is; How can I bypass this warning using <CFHTTP>?
Thanks
Better solution is to have the host of the service. Get a proper SSL certificate for that subdomain or a wildcard certificate that will allow them to have as many subdomains as needed with a single certificate.
I have been looking for a solution to this as well (a well-known payment gateway provider has an SSL issue on their server I have to work around). One solution I came up with was to put an entry into the server's hosts file and set it to the IP address of the hostname the SSL certificate was using. Fortunately their web server just accepts connections based on IP rather than hostname, so I was able to fool my server into thinking that I was connecting to the "proper" hostname published in the SSL cert and override the IP for that hostname in the public DNS. A way to tell Java that the name mismatch is "okay" would be nice though.