I’ve got nearly 25 years experience in the IT game with a range of skills that take in this task – DNS, Email, Web-Servers. However, for the last 15 years or more I’ve more or less outsourced the management of this to a third-party, or it simply hasn’t been my job. Once I used to teach Active Directory DNS to students when I was a Microsoft Certified Trainer, but that was way, way, way back in 1996-2003. Of course, there’s nothing new under the sun, as the Great Bard once said – and so I have gotten by ever since with core fundamentals. So this is both old and new too me, and if I was to be honest I’m not sure if the solution to my problem was the best or easiest. I might have just taken a sledgehammer to drive home a thumb tack. I’d be interesting hear if this process could made infinitely more simpler.
I think the ‘order’ of my process is good – especially as you need valid emails to confirm the transfer and setup of certain domains. But I’d also be interested that is this is the best way of doing it – could it have been done more efficiently in fewer steps. Finally, I’d be interested to know if this the ‘right’ way from a security and best practise perspective as well.
I would have liked to have a more exciting title to this blogpost – and one infinitely shorter! Being a Hunter S Thompson fan, I had thought of adding “A Strange and Terrible Saga”. But I actually I want to avoid the rabbit of an extended rant, and the convoluted shaggy-dog story of my experiences on Friday. It took me 6hrs to get this working, and I’m still mopping up the blood spatter today. This should have taken 30min-60mins tops including waiting for DNS caches to expire, and DNS records to be propagated on the interweb. However, I will spare you my personal grief this time, and just focus on the back-story, use-case, solution and workarounds in the hope that anyone facing similar heartache in the future will stumble upon this post and I will save them a bag of time. I’m just nice like that – after all I first got started with VMware, by just trying to be helpful. It takes you a long way in life I think.
Advice: If you are budding wannabe blogger who just wants your own domain, linked to Google Apps for email etc – together with your own WordPress setup. Don’t bother with this approach. It’s overkill. I would sign up to any number of hosted WordPress packages online, that will handle all of this for you in a nice simple easy enrollment process. This blog is hosted with Dreamhost.
The Problem – Back-story/Use-case:
As part of my endeavours to learn more about public cloud I’ve been looking at Amazon AWS. I’ve already put together an environment that leverages Amazon Router53 (DNS) together with multi-region Elastic Load-Balancer (ELB) together with IIS web-based instances running on ‘public’ subnets. I thought it would be good experience to do this using SSL certificates. I established a new DNS domain, registered and hosted with Amazon Route53, and then opted for for .net domain because that allows for the possibility of making my WHOIS information private, whereas this option did not exist for a .co.uk domain. Privacy is important to me, and I don’t think my postal address should be online for all and sundry to see. This is important to note, as it impacts on the SSL certificate enrollment. Registering the domain with Amazon Route 53 and Requesting an SSL certificate was relatively easy.
Where I became unstuck however – was In order for my SSL Provider to verify me and send me certificate they needed a valid email listed under WHOIS. This became tricky because that information as a.) private b.) the email used under the WHOIS information did not match the emails they would usually “expect” to use. That was tricky for me to easily provide because all I have is the raw DNS domain name, with none of the ancillary services that would normally surround it such as web-servers resolving to www.domain.net or any email infrastructure. Nor did I feel inclined to waste precious time putting together such services merely for a one-off email and verification process.
This process would have been relatively simple had I been requesting a certificate for www.michelle.com where those pieces of the puzzle were are in place, and much of the verification process had already been undertaken. However, I specifically wanted to use SSL with Amazon AWS and have it all in that environment, rather than doing the DNS work through dreamhost. Dreamhost is the company that hosts this blog. They are very good by the way.
So I hit upon the idea of associating my existing Google Apps subscription which supports my michelle.com domain, to also provide email services to my new mydomain.net domain. It is possible to register the mydomain.net domain as “alias” to mydomain.com. Once recognised by Google I would be able to create an firstname.lastname@example.org user within my mydomain.com subscription with google. After that I can then update my WHOIS information at Amazon Route53. And then contact my SSL provider to complete the verification process. Of course, working out HOW do this took time. I’m a pretty tech savvy – but this requires an area of skills, often using interfaces and procedures which are different to ones I’ve used in the past. So you need:
- DNS knowledge (with Amazon Route 53)
- Certificate Request Knowledge (Many routes – I used IIS 10 to create a CSR request)
- An account with Google, and knowledge of their Domain Registration/Validation process
- Further updates to Route 53 and the WHOIS information to change default settings
I don’t intend to write something step-by-step because as soon as I do – the UI’s will change. I’ve often found that Google help does NOT keep up with their many changes. Amazon on other hand appear to have a better handle on documentation – so there is no point in me trying to compete with Amazon or Google in the documentation stakes. It does illustrate the challenges of them managing such an “agile” environment compared to conventional shrink-wrapped software company. The documentation gets out of sync with the product…. To be honest I still don’t know WHY some processes provided by Google DID NOT work. And I still dont’ really know if the WAY I have done it the best or most efficient. It does HOWEVER, work. And that to me is what counts. BUT, if anyone can figure out what went wrong or suggest simple/easier way I would be indebted to them for that guidance.
Finally, I dare say Google Domains/Apps could be replaced with a different vendor if you subscription is with some other email supplier other than gmail. For instance I’m sure such a configuration could be achieved with Office360. Of course, any ordinary mortal just wanting a blog with their own domain, and bit of SSL to protect the login would be better of getting a hosting company to orchestrate all this – its much less heartache!
1,000 Foot View:
This is a simple number list that serves as a check-list to anyone (well mainly me) wanting to do this style of configuration…
- Register new domain with Amazon Route 53
- Login to Google Domains and create a New Domain Alias
- Use the cname record method to verify your domain
- Populate the Route 53 with the MX records for Google Mail servers
- Create a new user in Google Console for your preferred contact for the new domain
- Login to the new account, and (optionally) forward all email to an email address you do actually use!
- In Amazon Route 53 update your WHOIS information for the new ‘admin” email. receive a flurry of confirmation and validation emails!
- Generate a CSR for your domain (various methods)
- Submit CSR for your single host certificate (aka www.mydomain.net) or domain wild card certificate *.mydomain.net
- Use your new certificate as you see fit. In my case attached to two region specific ELB’s which act the SSL endpoint for inbound https requests – thus offloading the SSL process to ELB and away from your web-servers.
- Punch the air – and say wow, did I really do that. I must be some sort Cloud God loading over the Olympus of the Internet. Sit back. Have a cup of tea. Feel a little less full of yourself. It’s only software you know… 😉
NOTE: I won’t be covering step 8-11 as they are specific to your environment, and will vary from vendor to vendor. And mainly because this post will be LONG enough without adding that level of detail. My main interest is the interoperability between Amazon Route 53 and Google Apps to get this working.
Now in a LOT more detail…