Bind to <hostname> required for LetsEncrypt

Pydio Cells
1

While upgrading to 4.x I carefully followed https://pydio.com/en/docs/cells/v4/major-versions-upgrade-informations which states Cells Sites Bind URL should not use a domain name anymore.

I used to have the following configuration:

+---+--------------------------------------+--------------+----------------------------------+
| # |               BIND(S)                |     TLS      |           EXTERNAL URL           |
+---+--------------------------------------+--------------+----------------------------------+
| 0 | https://141.94.xxx.yyy:8080,         | Lets Encrypt | https://files.xxxxxxxxxxxxxx.org |
|   | https://files.xxxxxxxxxxxxxx.org:443 |              |                                  |
+---+--------------------------------------+--------------+----------------------------------+

So I removed https://files.xxxxxxxxxxxxxx.org:443 from the bind(s) to only keep the (public) IP address. (I don’t know why it needs to be public by the way) resulting in this:

+---+-----------------------------+--------------+----------------------------------+
| # |           BIND(S)           |     TLS      |           EXTERNAL URL           |
+---+-----------------------------+--------------+----------------------------------+
| 0 | https://141.94.xxx.yyy:8080 | Lets Encrypt | https://files.xxxxxxxxxxxxxx.org |
+---+-----------------------------+--------------+----------------------------------

Anyway, when running 4.0.x it failed: Caddy refused to work because of a LetsEncrypt failure:
Obtain: subject does not qualify for a public certificate: 141.94.xxx.yyy.

Indeed, .config/pydio/cells/caddy/autosave.json was showing:

    "tls": {
      "automation": {
        "policies": [
          {
            "issuers": [
              {
                "ca": "https://acme-v02.api.letsencrypt.org/directory",
                "email": "log@xxxxxxxx.org",
                "module": "acme"
              }
            ],
            "subjects": [
              "141.94.xxx.yyy"
            ]
          }
        ]
      }
    }

When adding back https://files.xxxxxxxxxxxxxx.org:443 as a secondary bind to the site configuration, I found that .config/pydio/cells/caddy/autosave.json showed:

    "tls": {
      "automation": {
        "policies": [
          {
            "issuers": [
              {
                "ca": "https://acme-v02.api.letsencrypt.org/directory",
                "email": "log@xxxxxxxxxxxxxx.org",
                "module": "acme"
              }
            ],
            "subjects": [
              "files.xxxxxxxxxxxxxx.org",
              "141.94.xxx.yyy"
            ]
          }
        ]
      }
    }

When restarting cells, logs still showed a failure to obtain a certificate for the IP address but at least it got one for the hostname what finally allowed for a fully working https connection.

The issue is that I needed to disrespect the documentation guidelines to get an SSL-enabled instance working.

I think that even after all these iterative improvements to the site/microservice/configuration along these years, there is still some some room for improvements :wink:

2

Thanks very much for reporting.

It’s probably wrong that the bind address should be the only one in the list of subjects. As mentioned in the docs, the bind address is there for binding the app onto a network interface (it doesn’t need to be public). External url should only be used for external routing to the application.

At first glance, it looks as if we’re passing the right information to our caddy instance but clearly from your tries, the tls automation policy configuration is missing something for lets encrypt.

I’ll look into it and I’ll keep you posted.

Thanks,
Greg

1 Like
3

I think so. Some strange things found in the logs:

{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.grpc.registry","msg":"ready"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.grpc.broker","msg":"ready"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.manager","msg":"Discovery services started, carry on to other services"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"✅ Using the local CA at \"rootCA.pem\" ✨"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"✅ Created a new certificate valid for the following names 📜"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":" - \"10.0.0.1\""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":" - \"127.0.0.1\""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":" - \"141.xxx.yyy.zzz\""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":" - \"localhost\""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"✅ The certificate is at \"53fa2336c7df264c0db753xxxx.pem\" \n and the key at \"53fa2336c7df264c0db753xxx-key.pem\""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"👉 If you are behind a reverse proxy, you can either install the RootCA on the proxy machine trust store, or configure your proxy to `insecure_skip_verify` for pointing to Cells."}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"👉 If you are developing locally, you may install the RootCA in your system trust store to see a green light in your browser!"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":"🗒  To easily install the RootCA in your trust store, use https://github.com/FiloSottile/mkcert. Set the $CAROOT environment variable to the rootCA folder then use 'mkcert -install'"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.server.caddy","msg":""}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.gateway.grpc","msg":"Configuring self-signed configuration for gRPC gateway to allow full TLS chain."}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.rest.share","msg":"starting","service":"pydio.rest.share","hook router to":"/a/share"}
{"level":"info","ts":"2022-12-23T01:58:33+01:00","logger":"pydio.rest.update","msg":"starting","service":"pydio.rest.update","hook router to":"/a/update"}
4

Hello,

After investigation, we came to the decision of altering the documentation to include an exception for Let’s Encrypt. The internal caddy that comes with Cells requires us to use the domain name and standard port in case of a Let’s Encrypt configuration of TLS. That is to be able to serve the webservers created during the ACME challenge verification step of the Let’s Encrypt process. That config directly comes from the binding address and we don’t really want to reinvent the wheel.

So now for LetsEncrypt configuration you should bind to your domain name and standard port, and have the full URL as external URL.

Hope that clarifies it,

Thanks,
Greg

5

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