Posted on Mar 5, 2017 5 mins read
At StarLeaf we had a need to secure our SendGrid click tracking links, unfortunately our provider, SendGrid, had no way of sending HTTPS traffic with their in place white labeling solution. This is how we solved that.
This solution does not solely apply to SendGrid as it’s a generic way to proxy HTTP URL’s to HTTPS. You can apply the solution I build here to nearly anything that requires proxying. CDN’s are a wonderful thing :)
SendGrid really only provides an out of the box solution for working with Cloudflare and like many other enterprises we use Dyn / Route 53 for DNS and CloudFront for CDN services. We obviously like our fine grained control. We had some motivation to change things because one of our customers apparently cannot follow any links that are plain text (HTTP). Our original setup with SendGrid was using their legacy whitelabeling system which involved a CNAME to refer to SendGrid.net.
Simple right? Simple isn’t always best but it does get the job done fast. SendGrid does not have the ability to handle our SSL Certificate, therefore, we had to establish our own intermediary.
When we looked at enabling HTTPS on the click tracking links we found out that SendGrid recommends a proxy method via CDN but only officially supports Cloudflare and another provider. CloudFlare lacks some GeoDNS and round robin functionality which can be quite nice in enterprise so obviously this solution was not for us.
Another solution we looked at was possibly including Cloudflare at the bottom of our resolution list and only letting it handle those records for click tracking. To us this was kind of messy and now involved a third DNS provider and eliminates the possibility of failover with another provider. We also got another challenge from management which was that this should be an exercise in maintaining legacy support. We had sent out thousands of emails with HTTP links so we should continue to support HTTP and just proxy the link to HTTPS.
My team mate and I came up with a solution to convert the DNS white label on SendGrid over to their new CNAME based system.
SendGrid provided us with the destination address and the destination for the CNAME records. Seemingly, they didn’t care about what happens in the middle so long as the request is finally received via HTTPS with a trusted certificate. We built out the following plan:
We take on a bit of cost via CloudFront, but we gain end to end encryption and we’re retaining any old plain text traffic at the same time. The other challenge is that these URL’s are production and SendGrid has a window of time that they implement your SSL links in. This can make for a theoretical downtime of sorts. A lot of this hinges on the fact that we use DynDNS whose changes propagate all around the world in minutes.
Create Replica Amazon CloudFront Distribution from existing Beta Cloud Distribution. This may need up to one hour to propagate so complete it one hour prior to planned changeover. (another_hash.cloudfront.net)
Setup verification and point to link.whatever.com to point at CloudFront (Old links will still work)
Enable proxying of requests in CloudFront.
Remember that any changes you make to CloudFront take time to take effect, so change them once and change them right.
I’m going to make the assumption that the SendGrid portion of this is quite self explanatory. Their CNAME records will start working immediately once you implement them so you should not incur more than a minute of downtime during this process. This is also a good point to stop and test to make sure everything is going smoothly.
Here’s your CloudFront settings.
This’ll take a bit to propagate but everything will work from here on out. Once SendGrid gives you the thumbs up, turn on HTTPS redirection for the Viewer Policy.
I hope this helps anyone that’s been looking for a viable solution to implement SendGrid whitelisting with AWS!Tutorials SendGrid AWS CloudFront