I cannot get my DKIM settings verified with Amazon Web Services SES (Simple Email Service) and Cloudflare. The CNAME records provided by AWS seem to be configured on Cloudflare correctly, yet I am notified by AWS that DKIM verification fails.
What am I doing wrong?
By default, Cloudflare CNAME records are proxied, which is one often expects:
However, that should not be so with DKIM records. Edit the DKIM CNAME records to set them in DNS only mode:
Related
I want to add an HTTPS listener to my AWS Application Load Balancer. I see from this thread that it's not possible without a custom domain (and the certificate that authenticates it). My question is why? Couldn't there be a certificate belonging to AWS, and it would certify, when people connect to my ALB, that "yes you are indeed talking in HTTPS with domain blabla.us-west-1.elb.amazonaws.com"?
You need a certificate to create a listener for your ALB, certificate manager can help you and public certificates are free, you need a custom domain to validate that you are the owner of that or you can upload your own certificate.
I've just created a space on the Digital Ocean cloud.
To enable CDN, it asks for an SSL.
My domain manager is Cloudflare.
I've created a CNAME on the Cloudflare DNS settings page.
Then created an origin server SSL certificate and added those keys to the Digital Ocean subdomain settings page.
But I'm getting this error when I'm visiting the URL.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
How can I fix this issue?
Use SSL certificate for your original domain then it will work. Don't use a certificate generated by Cloudflare, because that is for something else that Cloudflare side use for to enable strict policy in their side.
Submitting the CNAME in App Platform before adding the record in the DO networking tab causes App Platform to register the domain with CloudFlare before it exists. There is a 30 minute TTL on this record then your domain will start working.
However, as a workaround you can remove the custom domain, let your app deploy, then re-add the custom domain and it should start working almost instantly.
In one of projects we use CloudFlare and its cf-connecting-ip header to get a visitor IP address. But I'm not sure that the info can be fully trusted. For example, a bad user somehow had obtained real IP of our server, and connecting directly to it, putting fake IP address to the cf-connecting-ip header, and pretending that it was a legitimate CF-proxied request.
I examined headers for CF-proxied requests, and saw the cf-request-id header. But it's unique per a request, and I cannot see there any fixed secure key which I can use to verify that the request was legitimate.
How to ensure that a request was really proxied by CF?
You may want to use the Authenticated Origin Pulls feature from Cloudflare:
Authenticated Origin Pulls let origin web servers strongly validate that a web request is coming from Cloudflare.
We use TLS client certificate authentication, a feature supported by most web servers, and present a Cloudflare certificate when establishing a connection between Cloudflare and the origin server.
By validating this certificate in origin server configuration, access can be limited to Cloudflare connections.
You will need to download the client certificate from Cloudflare and configure your webserver to enforce the certificate check.
The referenced page has instructions on how to set up client certificate in Apache and Nginx.
I am trying to issue a SSL certificate for my loadbalancer, which serves traffic to an application hosted on GKE cluster in the backend. I have reserved a static IP for the loadbalancer, and I am able to access the application over HTTP.
Early this week, I had managed to generate SSL certificates and attached it to the load balancer using the GCP managed SSL certificates, and my domain was working on HTTPS network. However I had to delete the loadbalancer and launch it again using the Kubernetes Ingress. But now I am not able to apply the certificates to the loadbalancer. The certificates fail to provision with the error: FAILED_RATE_LIMITED.
Now I have deleted all the previously generated certificates on my account, and there is a single certificate now. According to the error, I have exhausted the number of GCP managed SSL certificates on my account. But I have deleted all the previously generated certs and I have almost waited for 10-11 hours, but the issue still exists. Is there a solution to this?
there a several questions for Heroku, Cloudflare and DNS but doesn't match mine. I've configured Heroku with automated certificate management (ACM) and Cloudflare of course is configured to serve SSL from itself. With this I want to ensure, that requests are also encrypted between Cloudflare and Heroku.
SSL works perfect for the Client. Problem is, that Heroku can't verify the DNS settings from Cloudflare (which is documented from Heroku as ACM isn't working with Cloudflare this way). Of course I could disable it, but then the traffic isn't encrypted anymore between Heroku and Cloudflare, which would be the worst case.
Someone knows how I solve this and ensure the entire communication between my Heroku Apps, Cloudflare and the Client is encrypted?
That would be great, I look forward to your answers/questions.
Okay, after a few more researches I guess got the solution. In my case with Cloudflare, Heroku doesn't work with ACM in paid plans above Hobby dynos (as said from Heroku itself). Even the option to generate "Origin Certificates" on Cloudflare and put them into your Dyno config isn't working (tried with an ECDSA one).
It's possible to pay Heroku to be able to modify the SSL Endpoint with the "SSL Endpoint Add-on" (20$/mo) and modify Heroku in the way it works, which isn't an option to me.
Update: I the meantime Heroku did update the SSL behavior and you're able to upload an origin certificate (from Cloudflare for instance).