Media Temple: Problem issuing cert for days

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: I tried adding a cert via Plesk which I have done many times before with no issue.

It produced this output:
Could not issue an SSL/TLS certificate for

Could not issue a Let's Encrypt SSL/TLS certificate for . Authorization for the domain failed.
Invalid response from
Type: urn:ietf:params:acme:error:dns
Status: 400
Detail: DNS problem: query timed out looking up A for

My web server is (include version): Hosted at Media Temple. It is a DV w/SSDs (CentOS 7) - Level 3. It is running Apache.

The operating system my web server runs on is (include version): CentOS 7

My hosting provider, if applicable, is: Media Temple

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Plesk

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): unsure

1 Like

Quite strange, as there seems to be no issue with your hostname:

Both sites don't report any problem and can resolve the hostname without issues.


Welcome Back to the Let's Encrypt Community :slightly_smiling_face:

I concur with @Osiris. Honestly, I'm rather baffled by what you're seeing. I've ran several DNS A record checks of my own with no apparent issues yet Let's Debug reports the failure:

I did notice a redirect that might cause validation problems later, but it has nothing to do with the current issue.
301 Moved Permanently
200 OK
1 Like

Once we have a cert the redirect will force https traffic, so I'm not too concerned about that. So, how do we resolve this so I can issue a cert for this site?

1 Like

I'm saying that the current redirect strips off the request URI, which could make satisfying an http-01 challenge difficult.

1 Like

It might also be helpful to note that I can't issue any certs on that server right now on any domains. Existing certs seem to renew just fine but I haven't been able to get a new one in a few days.

1 Like

This was likely a temporary problem with Media Temple's nameservers.

1 Like

Might be worth contacting them. They might be able to diagnose and resolve this issue quickly.

1 Like

I have contacted them and they said they thought the issue was with Let's Encrypt

1 Like

I'll ping the staff. Maybe they'll have an immediate indication.


We're rather baffled here. Any light to shed?

Issue resolved itself. Maybe temporary.

1 Like

Don't bother...or maybe still bother I don't know, but we can mark this resolved. It turned out to be the browser. I tried in Firefox and had these issues. Contact Media Temple again and they were able to issue one for me, and it turns out that the reason was Firefox...or maybe caching in Firefox, or something. When I try in Chrome it works.

Err.. I'm pretty sure a browser cannot change the authorization attempt of the Let's Encrypt validation server: there's no step in the validation where the browser has any role at all..?


That makes zero sense, but I'm glad it worked. :slightly_smiling_face:


Might have been a temporary issue.

1 Like

I think it was something that Firefox was holding on to in the cache that was throwing everything off.

What @Osiris is saying is that this:

cannot possibly be caused by anything in your browser (unless your browser somehow controls the DNS servers for your website).

That error message is directly from Boulder (Let's Encrypt's CA software) when querying your DNS servers. Your browser isn't anywhere in the equation when that happens.

1 Like

The OP is using Plesk to manage his server. What is the user interface of Plesk, is it a browser by chance?


It is for sure, @bruncsak.


I guess that it is possible that a many days old log file of the ACME client was presented in the browser, as provided by Plesk.


I tested the domain less than two hours ago with Let's Debug though. Same story.

Failed then:

Succeeds now: