# Creating certificate fails for CDN sub domain

**URL:** <https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664>\
**Category:** Help\
**Created:** [August 11, 2019, 11:57pm UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664 "2019-08-11T23:57:44Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![MichaelJC91](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@MichaelJC91](https://community.letsencrypt.org/u/MichaelJC91)\
**Post date:** [August 11, 2019, 11:57pm UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/1 "2019-08-11T23:57:44Z")

</div>

I’ve got a CDN setup with Digitalocean and I manage my domains with GoDaddy. I’ve setup the CDN and created a CNAME of stagingassets.tradiematepro.com.au to point to my Digitalocean CDN. When I go to create a certificate for the sub domain it returns this error:

Failed authorization procedure. stagingassets.tradiematepro.com.au (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from [http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/6ePqsmLxyigmoo3CB8LOLUnx8FhBFL6wZaTH0veMse8](http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/6ePqsmLxyigmoo3CB8LOLUnx8FhBFL6wZaTH0veMse8) [205.185.216.42]: “\<?xml version=\"1.0\" encoding=\"UTF-8\"?\>`AccessDenied`stagingassetstx0000000”

IMPORTANT NOTES:

- The following errors were reported by the server:

What am I doing wrong?

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [August 12, 2019, 12:15am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/2 "2019-08-12T00:15:48Z")

</div>

[https://stagingassets.tradiematepro.com.au/](https://stagingassets.tradiematepro.com.au/) already uses a Let’s Encrypt certificate, issued a few days ago. Do you need another one?

---

<div class="post-metadata">

**Author:** ![MichaelJC91](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@MichaelJC91](https://community.letsencrypt.org/u/MichaelJC91)\
**Post date:** [August 12, 2019, 12:35am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/3 "2019-08-12T00:35:14Z")

</div>

I created that certificate with an old server that I had to shut down. Because there’s no cron job that exists anymore it will eventually expire. Sorry I should have included that information.

---

<div class="post-metadata">

**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\
**Post date:** [August 12, 2019, 6:37am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/4 "2019-08-12T06:37:13Z")

</div>

Hi @MichaelJC91

> [@MichaelJC91](#):
>
> Domain: stagingassets.tradiematepro.com.au

what's the ACME-client and command you have used?

* * *

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. [crt.sh | example.com](https://crt.sh/?q=example.com)), 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:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

* * *

Do you run your client on that 205.185.216.42 - ip address?

The subdomain is completely blocked ( [https://check-your-website.server-daten.de/?q=stagingassets.tradiematepro.com.au](https://check-your-website.server-daten.de/?q=stagingassets.tradiematepro.com.au) ):

| Domainname | Http-Status | redirect | Sec. | G |
| --- | --- | --- | --- | --- |
| • [http://stagingassets.tradiematepro.com.au/](http://stagingassets.tradiematepro.com.au/) | | | | |
| 205.185.216.10 | 403 | | 1.060 | M |
| Forbidden | | | | |
| | | | | |
| • [http://stagingassets.tradiematepro.com.au/](http://stagingassets.tradiematepro.com.au/) | | | | |
| 205.185.216.42 | 403 | | 0.033 | M |
| Forbidden | | | | |
| | | | | |
| • [https://stagingassets.tradiematepro.com.au/](https://stagingassets.tradiematepro.com.au/) | | | | |
| 205.185.216.10 | 403 | | 3.360 | M |
| Forbidden | | | | |
| | | | | |
| • [https://stagingassets.tradiematepro.com.au/](https://stagingassets.tradiematepro.com.au/) | | | | |
| 205.185.216.42 | 403 | | 3.104 | M |
| Forbidden | | | | |
| | | | | |
| • [http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de](http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de) | | | | |
| 205.185.216.10 | 403 | | 1.106 | M |
| Forbidden | | | | |
| Visible Content: \<?xml version="1.0" encoding="UTF-8"?\> AccessDenied stagingassets tx00000000000000e5e3f0c-005d510629-4c23a1-sgp1a 4c23a1-sgp1a-sgp | | | | |
| | | | | |
| • [http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de](http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de) | | | | |
| 205.185.216.42 | 403 | | 0.040 | M |
| Forbidden | | | | |
| Visible Content: \<?xml version="1.0" encoding="UTF-8"?\> AccessDenied stagingassets tx00000000000000e5e3f0c-005d510629-4c23a1-sgp1a 4c23a1-sgp1a-sgp | | | | |

There is an Xml-error-output.

And there is no Server header. Apache? Nginx? So `--apache` or `--nginx` may not work. To use webroot, you must be able to skip that standard message. Or you have to configure the two directories

```nohighlight
/.well-known/acme-challenge

```

with the correct rights.

---

<div class="post-metadata">

**Author:** ![MichaelJC91](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@MichaelJC91](https://community.letsencrypt.org/u/MichaelJC91)\
**Post date:** [August 12, 2019, 10:58pm UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/5 "2019-08-12T22:58:12Z")

</div>

> _ **what’s the ACME-client and command you have used?** _  
> sudo certbot --expand -d staging.tradiematepro.com.au -d stagingassets .tradiematepro.com.au

@JuergenAuer My main staging site runs on **staging.tradiematepro.com.au** I'm testing this whole process with my testing site then I'll migrate to my main site.

The way the Digitalocean CDN works is if you go to a URL with an asset then it's not forbidden - [https://stagingassets.tradiematepro.com.au/1.png](https://stagingassets.tradiematepro.com.au/1.png)

My domain is:  
stagingassets.tradiematepro.com.au

I ran this command:  
sudo certbot --expand -d staging.tradiematepro.com.au -d stagingassets .tradiematepro.com.au

It produced this output:

```
 - The following errors were reported by the server:

   Domain: stagingassets.tradiematepro.com.au
   Type: unauthorized
   Detail: Invalid response from
   http://stagingassets.tradiematepro.com.au/.well-known/acme-challenge/6B4ePeB_wwsJ5FiVlOE4Uk2-BBdRDs3L6ZH-eIUtNC8
   [205.185.216.10]: "<?xml version=\"1.0\"
   encoding=\"UTF-8\"?><Error><Code>AccessDenied</Code><BucketName>stagingassets</BucketName><RequestId>tx0000000"

```

My web server is (include version):  
Apache/2.4.29

The operating system my web server runs on is (include version):  
Ubuntu 18.04

My hosting provider, if applicable, is:  
GoDaddy

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):  
No

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

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [August 12, 2019, 11:03pm UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/6 "2019-08-12T23:03:45Z")

</div>

That subdomain is running on DigitalOcean Spaces, an object storage service, right?

The requests are being answered by the Spaces servers instead of the computer you’re running Certbot on.

I don’t understand why you’re trying to create a certificate for that subdomain – as I understand it, Spaces can automatically issue and renew (Let’s Encrypt) certificates on its own.

There should be various ways to issue your own certificates, manually or in an automated way, but I don’t understand what you would do with a certificate.

---

<div class="post-metadata">

**Author:** ![MichaelJC91](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@MichaelJC91](https://community.letsencrypt.org/u/MichaelJC91)\
**Post date:** [August 13, 2019, 12:26am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/7 "2019-08-13T00:26:36Z")

</div>

DigitalOcean spaces creates a certificate for you if I use Digitalocean to manage DNS, but I can’t because I’m using GoDaddy and sadly it needs to stay that way for now.

Digitalocean has the option to bring your own certificate for my sub domain. Hence the reason why I’m trying to create one for myself.

---

<div class="post-metadata">

**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\
**Post date:** [August 13, 2019, 12:36am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/8 "2019-08-13T00:36:53Z")

</div>

Oh. I’m surprised DigitalOcean can’t do it if you’re using a different DNS provider (with HTTP or TLS-ALPN validation).

The simple, very manual thing you can do is use `--manual` instead of `--webroot`, and manually upload the validation file to Spaces (and then delete it afterwards).

The complicated, automated thing to do is to write a Certbot plugin or hooks to upload (and delete) the validation file using the Spaces API, and then upload the new certificate using DigitalOcean’s API for that.

Edit: I forgot, you weren’t using `--webroot`. You were using (implicitly) `--apache` or `--nginx`.

In any case, use `sudo certbot certonly --manual`.

I’d suggest using two different certificates, one for `staging.tradiematepro.com.au` using the apache or nginx plugin, and one for `stagingassets.tradiematepro.com.au` using certonly and the manual plugin.

---

<div class="post-metadata">

**Author:** ![MichaelJC91](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@MichaelJC91](https://community.letsencrypt.org/u/MichaelJC91)\
**Post date:** [August 14, 2019, 12:20am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/9 "2019-08-14T00:20:23Z")

</div>

Yeah, it’s a massive pain. So if I’m understanding correctly the code will be:

```
sudo certbot certonly -d domain.com.au --manual

```

Is that right?

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [September 13, 2019, 12:20am UTC](https://community.letsencrypt.org/t/creating-certificate-fails-for-cdn-sub-domain/99664/10 "2019-09-13T00:20:26Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
