Reported earlier this week as 
<> - posting to list per 
request on that bug:

In January 2010, I reported two issues to GoDaddy, with an example certificate 
that should have been rejected:
 - their website-based authentication required a request to an URL including a 
random string to include the same random string. A 200 was not required, but 
even with a 200 requirement, this would have not have been secure for many 
common website configurations; this appears to be at least extremely similar to 
the current issue
 - their DNS-based authentication required random subdomain to exist as a CNAME 
record - but the target was not specified. This meant that anyone could get a 
certificate for any domain that had a wildcard CNAME (e.g. ‘* CNAME @‘ is 
particularly common).

GoDaddy fixed these in September 2010. I am posting as I believe that GoDaddy 
should have invested in automated testing for these issues as a best practice 
(even if not required by industry agreements at the time) and any other 
verification failures that have been reported to them without publication.

I do not appear to still have access to my original GoDaddy tickets; timeline 
and details from my notes are below (CNAME incident first):

The new incorrect issuance with non-200 responses appears to be the same as one 
of two issues I reported (and was fixed) in 2010:

I reported two issues to GoDaddy back in 2010 (included after timeline) - the 
second one appears to be the same bug as the new incident being discussed at!msg/
 - timeline:

2010-01-09: I wanted an SSL certificate for my domain; I read GoDaddy’s 
instructions, and realized that my existing configuration probably matched 
their requirements. I got my SSL certificate with no changes to my DNS or 

2010-01-10: Notification sent to godaddy (Incident ID 8143623)

2010-01-20: Second notification sent to godaddy (Incident ID 8214596)

2010-01-21: Confirmed the flaw still exists - I got go daddy to issue me a 
certificate for a friend’s domain (consent 
given, but no cooperation)

2010-08-26: Reported again - had not yet received a response - (id 9711250)

2010-09-03: Phone call with Todd Redfoot (Chief information security officer)
2010-09-23: Email from Todd Redfoot confirming fix deployed

My report from 2010 is below - the first one is no longer valid given the 
switch to TXT-records for authentication.

----- 1. CNAME verification ——

 In short: if a domain had a wildcard CNAME, anyone could get a certificate for 
that domain from GoDaddy.

I have tested this approach, and got a godaddy signed certificate with consent 
but not cooperation (and godaddy not being informed of consent).

1. Find a domain which appears to have a wildcard CNAME record (i.e. "dig" returns any CNAME record)

2. Ask for permission from the owner (optional if blackhat….)

3. Create a CSR for the domain

4. Sign up for a godaddy domain verified certificate (referred to on the site 
a mixture of "Standard SSL" or "Turbo SSL" - same product)

5. Submit your CSR

6. Godaddy will attempt some verification via whois; wait a few hours for this 
to fail. They will email to let you know when this happens

7. Sign in to the web panel, and select "domain-based verification"

8. It will immediately confirm that verification was successful

9. In a few minutes, you can download a certificate for the domain

Godaddy's DNS verification is as follows:
- Create a random code
- Require you to make it so that returns a CNAME 
- The value of the CNAME record is irrelevant and not specified

So, you can get a domain-verified SSL certificate for a domain with anything 
like any of the following in the zonefile:


----- 2. Web-based verification ------

Instructions as above, except:

1. Find a domain where a not-found page returns a page including the URL 
requested. I'd assume that the site must also be misconfigured to return a 200 
response instead of 404, but this is a fairly common misconfiguration.

7. Select web-based verification

Similar cause; godaddy require that 
returns a page including godaddyRandomCode

 - Fred
dev-security-policy mailing list

Reply via email to