SSL causes cypher mismatch

[cmbirk]

I've gotten the application running on AWS's EKS product. I'm trying to get the domain to resolve correctly. I have ssl enabled for each of the services in the chart and have been able to get the IP for the ingress controller. I'm using Cloudflare for my DNS provider and have added an un-proxied A record that points to the external IPV4 for the ingress controller.

When I try to access the application, however, I get an error that the browser can't get a secure connection - Unsupported protocol The client and server don't support a common SSL protocol version or cipher suite.

@dcrdev is there additional setup necessary on Cloudflare to get ssl to terminate correctly?

[dcrdev]

@cmbirk if this is unproxied, then it likely has little to do with cloudflare as it's just dns, unless you are using dnssec (dns over tls) . Couple of questions:

Is this still using the nginx default ssl cert? If this is the case, it's self signed and issued against localhost and is therefore invalid and will not work be valid to any browser when accessed raw. With cloudflare full encryption - this doesn't matter for dev environments when proxied, as e2e encryption is maintained, it's just not validating the ca issuer. In production I would recommend using strict mode and either buying a certificate or using a cloudflare origin certificate : https://dash.cloudflare.com/account_id_goes_here/domain_goes_here/ssl-tls/origin .

What is the output of?

## find name of an nginx controller pod
$ kubectl get pod

$ kubectl logs <name_of_nginx_controller_pod> | tail -n 1000

If it is actually proxied:

• Are you using the nginx default certificate:
  • Yes: it's self signed - make sure strict mode is off in cloudflare security, so that it's not validating the certificate; this will not work. If you have selected strict from the get go - cf will likely be unable to issue a csr for it's own certificates.
  • No: have you made sure that both private key and certificate are in pem format, are b64 encoded and referenced correctly in the ingress config inside the helm chart.

[cmbirk]

@dcrdev when I proxy the domain on Cloudflare I get a 525 error from Cloudflare saying the SSL handshake failed.

I am using the nginx default cert. I haven't installed any other certs, and I'm using Cloudflare full security ( not strict ).

Requested logs are included below:

logs.txt

[dcrdev]

The logs show the process sighup repeatedly, also shows that the tls secret does not exist. Is your cluster rbac enabled?

Either way at this point I would just create the secret yourself and rather than generate a new self-signed cert, I would use an origin certificate: 1) Click create cert

2) Generate cert with rsa

3) Save cert and key Copy the cert (1st box) into a raw text file called cert.pem, do the same for the second box except call it key.pem; make sure to copy all of it including begin/end.

4) Create the secret

kubectl create secret tls tls-secret \
    --key key.pem \
    --cert cert.pem

5) Reload the controller

kubectl delete pod <controller_pod> #helm will bring the pod back for you automatically here

[cmbirk]

That appears to have worked for the root domain! I'm getting errors in the web pod not being able to access the api, however. The specific error I'm getting is:

Error: Network error: request to https://api.shop.example.com/graphql failed, reason: getaddrinfo ENOTFOUND api.shop.example.com api.shop.example.com:443

I'm trying to run this at a multi-level subdomain.

Eg. ( using example.com ) shop.example.com - web api.shop.example.com - api etc, etc.

I have the certificate set up for *.example.com, *.shop.example.com, example.com, and shop.example.com. I also have CNAME records pointing api.shop to shop.example.com.

Does it make sense that the CNAME DNS records wouldn't be resolving inside the cluster? I'm also not able to get a secure connection to the api.shop.example.com subdomain. Do these need different DNS records?

I appreciate all of the help @dcrdev !

[cmbirk]

BTW, I've replaced the actual urls with examples above

[cmbirk]

It appears that the default Cloudflare certs don't cover multilevel subdomains

https://community.cloudflare.com/t/subdomain-too-deep/81872

[dcrdev]

Yeah it needs to be a separate dns entry for multi-level, or a wildcard one with cname flattening.

I don't use multi-tiered subdomains myself, so haven't really tried it on cloudflare origin certs; but looks possible: ^ It wouldn't let me have two levels of wildcards, but you can add static entries.

Either way the validity of it doesn't matter too much for dev, the important part is the encryption between origin and cf. If you need sa validation, other options are: 1) Generate your own wildcard sa certificate:

$ cat << EOF > openssl.conf
[req]
req_extensions = v3_req
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.example.com
DNS.2 = *.*.example.com
EOF

$ openssl req -new -newkey rsa:2048 -sha256 -nodes -out cacert.csr -keyout cacert.key -config openssl.conf
$ openssl x509 -req -sha256 -days 365 -in cacert.csr -signkey cacert.key -out cacert.crt

2) LetsEncrypt via cert-manager - https://docs.bitnami.com/tutorials/secure-kubernetes-services-with-ingress-tls-letsencrypt (step 3)

[cmbirk]

I've tried this on a regular domain as well. I'm thinking the web pod can't access external urls? Is that a possibility?

I'm able to load https://api.example.com/graphql in my browser, but the web node is erroring with:

Error: Network error: request to https://api.example.com/graphql failed, reason: getaddrinfo ENOTFOUND api.example.com api.example.com:443

[cmbirk]

It looks like this was a lag in DNS propagation. It's running!

Thank you so much @dcrdev and keep an eye out for a documentation PR :)

[dcrdev]

This looks to be solbed.