Hello,
nextcloudpi docker only works if set on port 80 or I can use another port? since I have already used port 80 for a web server.
You will need port 80 for it to register Let’s Encrypt certificates. Beyond that, all you want port 80 to do is redirect to 443.
1 Like
So after registering the Let’s Encrypt certificates, can I change the port?
You can, but the renewal will fail. Nextcloud itself has no specific need for HTTP to be allowed. Most people leave the port open but then redirect traffic to HTTPS. That way the certificate renewal can be automatic.
1 Like
Or use:
DNS-01 challenge
This challenge asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name. It is harder to configure than HTTP-01, but can work in scenarios that HTTP-01 can’t. It also allows you to issue wildcard certificates. After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN> . Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!
Since automation of issuance and renewals is really important, it only makes sense to use DNS-01 challenges if your DNS provider has an API you can use to automate updates. Our community has started a list of such DNS providers here. Your DNS provider may be the same as your registrar (the company you bought your domain name from), or it might be different. If you want to change your DNS provider, you just need to make some small changes at your registrar. You don’t need to wait for your domain to be close to expiration to do so.
Note that putting your fully DNS API credentials on your web server significantly increases the impact if that web server is hacked. Best practice is to use more narrowly scoped API credentials, or perform DNS validation from a separate server and automatically copy certificates to your web server.
Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.
Most DNS providers have a “propagation time” that governs how long it takes from the time you update a DNS record until it’s available on all of their servers. It can be hard to measure this because they often also use anycast, which means multiple servers can have the same IP address, and depending on where you are in the world you might talk to a different server (and get a different answer) than Let’s Encrypt does. The best DNS APIs provide a way for you to automatically check whether and update is fully propagated. If your DNS provider doesn’t have this, you just have to configure your client to wait long enough (often as much as an hour) to ensure the update is propagated before triggering validation.
You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.
Pros:
- You can use this challenge to issue certificates containing wildcard domain names.
- It works well even if you have multiple web servers.
Cons:
- Keeping API credentials on your web server is risky.
- Your DNS provider might not offer an API.
- Your DNS API may not provide information on propagation times.
TLS-ALPN-01
This challenge was developed after TLS-SNI-01 became deprecated, and is being developed as a separate standard. Like TLS-SNI-01, it is performed via TLS on port 443. However, it uses a custom ALPN protocol to ensure that only servers that are aware of this challenge type will respond to validation requests. This also allows validation requests for this challenge type to use an SNI field that matches the domain name being validated, making it more secure.
This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers, but mainstream web servers like Apache and Nginx could someday implement this (and Caddy already does).
Pros:
- It works if port 80 is unavailable to you.
- It can be performed purely at the TLS layer.
Cons:
- It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
- Like HTTP-01, if you have multiple servers they need to all answer with the same content.
you can let one be a reverse proxy and keep both.
1 Like
Are you saying that I can keep both containers? I would like the php/apache container to remain on port 80. So do I have to transform the nexcloudpi container into a reverse proxy?
well. in fact it’s better to put a reverse proxy in front of both. and one that can handle letsencrypt certificates automatically.
something like this:
https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion
or
https://hub.docker.com/_/traefik
yes. and add millions more. depends on your server. 
e.g.: GitHub - ReinerNippes/selfhosted_on_docker: Install Selfhosted Stacks on Docker
if your apache only does http and not https, you can just make it proxy /.well-known/acme-challenge/ to the nextcloudpi container.
if your setup is more complicated, you’ll need to follow @Reiner_Nippes advice, otherwise just read this page on apache’s documentation website to figure out how to pass that path to ncp (that does not need to expose port 80 to the world, then, but it needs it to be reachable from the apache container, so use a docker network) https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse
it should be something like
proxypass /.well-known/acme-challenge/ http://nextcloudpi
(but check, check, check, I have never done this with apache)