GoDaddy TLS Certificate on AWS EC2 Instance

Co-authors: Aled Sage, Ashleigh Gray and Richard Downer

When generating a TLS certificate with GoDaddy, and setting that up on a VM, there are some gotchas, such as: using the root domain to validate the cert, and combining the pem files to include the full chain.

This blog describes those gotchas, and some troubleshooting tips that may be of help.

Requirements and Customer Context

A customer recently had the need to generate a wildcard TLS certificate with GoDaddy, and to set this up on a VM (in our case running Envoy as a TLS Proxy, but applicable to a wide range of use-cases). 

For anonymity in this blog, the example commands and output will all assume the wildcard cert is for *.myservice.prod.aws.example.com, and that it is installed on a VM at server1.myservice.prod.aws.example.com.

The DNS for myservice.prod.aws.example.com is managed in an AWS Route 53 Hosted Zone, with the parent domains managed in other AWS Hosted Zones in other AWS accounts in the AWS organization, reflecting the company’s structure (more details about how that works in AWS docs).

Generating the certificate with GoDaddy

We requested a wildcard certificate, choosing the option to verify domain ownership through DNS.

The GoDaddy docs for how to verify ownership are not the clearest: in brief, it requires creating a TXT record with a value supplied by GoDaddy, such as “abcdefghijklmnk0hdjd74g20k”. For the record’s “name”, it says:

“Type @ (If your DNS is hosted outside of GoDaddy, you may need to leave this blank)”

The “@” refers to how you write a DNS Zone File: “A free standing @ is used to denote the current origin.”

The docs also say:

“TXT records need to be added to the root level of the domain.”

What these two requirements mean in Route 53 is that you must create a new record in your root-level hosted zone (e.g. for “example.com”, in our example), and leave the “Record name” field blank. Set the Record type to TXT, and set the value to be the GoDaddy verification code inside double-quotes. You may already have such a TXT record in your hosted zone - in that case, edit this record and add the GoDaddy verification code inside double-quotes on a new line at the end of the existing value.

Luckily, the customer we were working with is not too process heavy - we could work with the folk responsible for administering the root domain to get the TXT record updated. However, in a big organisation such a ticket could take a long time to get processed!

As per GoDaddy instructions, one then asks GoDaddy to “check for updates” - it verifies the existence of the expected TXT record, and then you can get the certs.

Using the GoDaddy Cert files

GoDaddy gives you certificate files like the following:

gd_bundle-g2.crt
7654321ea15fa123.crt
7654321ea15fa123.pem  # this is identical to the crtfile

You will also have your private key file, used when originally requesting the cert (GoDaddy will never have your private key).

The file 7654321ea15fa123.crt has your certificate; and gd_bundle-g2.crt has details of the intermediate certificate authorities used by GoDaddy.

A web-service on a VM (e.g. like Envoy) expects to be configured with a single pem file and a private key file.

You have to combine the contents of 7654321ea15fa123.crt and gd_bundle-g2.crt. For example:

cat 7654321ea15fa123.crt gd_bundle-g2.crt > myservice.crt

Double-check myservice.crt to make sure that the combined file is formatted correctly. In particular, make sure that any END CERTIFICATE and BEGIN CERTIFICATE directives are on separate lines - if they end up being combined into a single line, the file format is invalid and it’s likely that your app will reject it.

Troubleshooting Tips

Checking your TXT records

You can verify that the DNS TXT record is created as expected with a command like:

dig -t txt example.com

You’d expect this to return something like:

example.com. 6850 IN TXT "v=spf1 -all"
example.com. 6850 IN TXT "abcdefghijklmnk0hdjd74g20k"

Examine the cert files

The command below shows details of the certs in a given pem or crt files:

openssl x509 -in 7654321ea15fa123.pem -noout -text

For example, our 7654321ea15fa123.pem file shows:

Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Validity
    Not Before: Apr 30 15:49:44 2025 GMT
    Not After : Apr 30 15:49:44 2026 GMT
Subject: CN=*.myservice.prod.aws.example.com

The gd_bundle-g2.crt shows two certificates.

The first:

Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
Validity
    Not Before: May  3 07:00:00 2011 GMT
    Not After : May  3 07:00:00 2031 GMT
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2

And the second:

Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
Validity
    Not Before: Sep  1 00:00:00 2009 GMT
    Not After : Dec 31 23:59:59 2037 GMT
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

We can see that our cert for CN=*.myservice.prod.aws.example.com is issued by an intermediate certificate authority, whose certificate was issued by the GoDaddy Root Certificate Authority.

Checking the web-service’s cert

When your web-service is up-and-running on the VM with your cert, you can connect to it and check its certs. There are a few ways to do this - you may want to do multiple of these if you are having problems!

Use a browser and inspect the certs

In a browser such as Chrome, go to your web server, such as: https://server1.myservice.prod.aws.example.com. This will tell you if there is a cert and if that cert is trusted.

Click on the “i” next to the address bar to get info about whether the site is secure, and about its certificate -  for example, showing the below.

However, the Chrome browser trusts the GoDaddy intermediary certificate - so if you skipped the step to combine the files 7654321ea15fa123.pem and gd_bundle-g2.crt, Chrome would not tell you of the problem!

Use curl to see basic certificate information

The curl command below with its verbose output will show you some details of the server certificate:

curl -vvI server1.myservice.prod.aws.example.com

You should see output like that below:

* Server certificate:
*  subject: CN=*.myservice.prod.aws.example.com
*  start date: Mar  7 05:09:55 2025 GMT
*  expire date: Jun  5 05:09:54 2025 GMT
*  subjectAltName: host "server1.myservice.prod.aws.example.com" matched cert's "*.myservice.prod.aws.example.com"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.

However, if you have not included the intermediate certificate authority, this would fail showing:

* Server certificate:
*  subject: CN=*.myservice.prod.aws.example.com
*  start date: Apr 30 15:49:44 2025 GMT
*  expire date: Apr 30 15:49:44 2026 GMT
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption

Use openssl to get full certificate information from the server

The command below will connect to the server and show you the the certificate:

openssl s_client -showcerts \
    -servername server1.myservice.prod.aws.example.com \
    -connect server1.myservice.prod.aws.example.com:443

Using this, you can see all of the certificates presented by the server. There should be at least two certificates - one for your certificate, and one for GoDaddy’s intermediate certificate. OpenSSL will also notify you if the certificate fails to validate for any reason (such as a missing intermediate certificate, or if the server name on the certificate does not match the address).

Better ways than GoDaddy certificates!

GoDaddy is a popular choice, but it’s more expensive and requires more manual steps than some other options - including manually handing certificate renewal.

AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) is our go-to first choice when working with AWS: it’s simple, free, and automatically manages certificate renewals for you. You can get ACM to generate the certificate for you, or import an existing certificate.

The user experience for generating a certificate, to verify domain ownership, is slick. If your domain is already in a Route53 hosted zone, it can do it all automatically for you. Otherwise, it asks you to create a CNAME Record at the DNS level of your cert - for example, it might ask you to create a record for _1234567890abcdef28a2f4bda9d3cd9d.myservice.prod.aws.example.com with the value _abcdefghddca0eacb148f6fa4a41b3a1.xlfgrmvvlj.acm-validations.aws. This is far nicer than GoDaddy: we are creating the record in our own hosted zone, rather than raising a ticket with another part of the business for a TXT record at the root domain.

However, ACM does not let you download the certificate material to install on a VM. It can only be used with AWS managed services, such as Application Loader Balancer ALB), Network Load Balancer (NLB), API Gateway, CloudFront, etc.

Usually, that’s not an issue: you can do TLS termination on the ALB, in front of your VMs, and keep your VMs private. You could use http on port 80 between the ALB and the VM, or for end-to-end encryption there are lots of options including using a self-signed certificate on the VM.

However, sometimes there is a business or technical reason why that is not possible - why the VM needs to have the certificate.

LetsEncrypt

LetsEncrypt is an excellent free service for generating certificates - it also allows automatic renewal.

This is our go-to choice when a cert is needed on the VM (except when business reasons prevent this).

Conclusions

Generating certificates with GoDaddy and hosting the certificates on the VM is certainly not our preference, but is necessary in some situations. TLS certificates can be very fiddly - that’s why we much prefer fully managed services like AWS Certificate Manager (ACM).

Hopefully you find the steps and gotchas described here useful, along with the troubleshooting tips.