Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ANAME verification for LetsEncrypt Certificates #755

Closed
abovethewater opened this issue Dec 6, 2020 · 4 comments
Closed

Support ANAME verification for LetsEncrypt Certificates #755

abovethewater opened this issue Dec 6, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@abovethewater
Copy link

馃殌 Feature

Support ANAME verification for HTTPS certificate generation

Have you spent some time to check if this issue has been raised before?

Issue created after discord discussion.
Only CNAME is allowed, but ANAME shouldn't be a major issue to add.

Have you read the Code of Conduct?

Yes

Pitch

A CNAME must point to an existing name, never an IP.
In the instance that a subdomain is created purely for AppWrite (e.g. api.mydomain.com), then a CNAME will not exist.
An ANAME can point to an IP address.

My personal workflow when installing AppWrite for the first time was to:

  • Read the documentation.

  • Create a DO Docker droplet (1CPU / 2GB)

  • Install AppWrite following the installation instructions

  • When prompted for the hostname (default localhost), I relaised I would need to choose a relevant name.

  • I then created a DNS entry for api.mydomain.com as an ANAME referencing the DO droplet created earlier.

  • Returned to installer and added that as the host.

  • Continued through setup until complete.

Upon completion of installation, I was able to access api.mydomain.com via a web browser, and AppWrite was fully working (fantastic result! No idea how often the first time install fails on many projects!)

The page however was not available via HTTPS via the browser as it uses a self-signed cert.

Following documentation for custom domains, I then created an extra CNAME for app.mydomain.com, which pointed to api.mydomain.com. Adding and verifying this in the console resulted in HTTPS being available for app.mydomain.com.

My suggestion would be to:

  • Document the hostname requirement in the installation documentation (what is it, what relevance does it have?)
  • Support ANAME DNS verification for Certificate Generation
  • Provide an option to auto verify on first start (or add the option to verify current domain in custom domains), allowing for out of the box HTTPS.

Notes:

  • Completely new to this, so there may be some confusion in terminology 馃檪
  • I presumed the hostname was tied to the DNS name, but this may well not be the case

Thanks, and keep up the good work.

@Glide7 Glide7 added the enhancement New feature or request label Dec 10, 2020
@eldadfux eldadfux self-assigned this Dec 10, 2020
@brandonroberts
Copy link
Contributor

@abovethewater we've recently added support for wildcards to platforms. Let us know if this is still relevant and feel free to reopen if so

@Pastajello
Copy link

Pastajello commented Jun 9, 2022

@brandonroberts I'm not sure this is the same thing You have on mind. Its not about adding a domain to the platform so it'll be recognized/cookies will be accepted etc. but about setting a LetsEncrypt certificate on the (sub)domain that's connected to the server AppWrite is hosted on.

I'm also having this problem and as adding a certificate to 'domain.com' is easy 'whatever.domain.com' is not.

Or it's me who doesnt understand what You are talking about :D

@rhengles
Copy link

@brandonroberts Yes, exactly what Pastajello said. Does appwrite support requesting wildcard certificates from Letsencrypt ?

@Pastajello
Copy link

@rhengles I'm not sure about wildcards, but its possible to get a subdomain working:
image

And then on vps a command where you put image:
docker compose exec appwrite ssl domain="www.appwrite.mydomain.com"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants