AkkomaGang/akkoma

Fork 94

[feat] Provide way to override root certs used for federation #585

New issue

Open

opened 2023-07-09 19:06:39 +00:00 by Gaelan · 6 comments

Gaelan commented

2023-07-09 19:06:39 +00:00

The idea

Provide a way to specify a root certificate that is always considered valid when making HTTPS requests to other instances.

The reasoning

I'm working on a (yet unpublished, but I intend to soon) tool for running a bunch of fedi instances locally for testing. Everything's running locally, so we can't use real Let's Encrypt certs; instead, I use a locally-generated self-signed CA. Naturally, for Akkoma to federate successfully, it needs to trust that CA.

Putting this in config.exs currently works in my setup:

    config :pleroma, :http, adapter: [pools: %{default: [conn_opts: [transport_opts: [cacertfile: "path/to/rootCA.pem"]]]}]

But only because I'm running on macOS without security on the PATH, so Erlang's :public_key.cacerts_get() fails. If it didn't (and there isn't as easy a way to engineer such a failure on Linux, which I'd like to support), Akkoma (http_children in lib/pleroma/application.ex, which calls maybe_add_cacerts in lib/pleroma/http/adapter_helper.ex) would replace my configuration with the discovered system certs, with no way to disable this behavior that I can see.

Other alternatives considered:

Configure Akkoma to use an unencrypted HTTP proxy (which is in turn considered to accept my CA) to access other instances: doable, but more moving parts. Also mildly annoying that Akkoma doesn't support (as far as I can see) connecting to an HTTP proxy over a Unix socket, so I need to juggle port numbers.
Patch Akkoma on my end to replace the root-finding logic. Again doable, but more of a pain, especially as I'd like to support a wide range of Akkoma versions (although I'm not sure how much churn there is in this part of the code in practice).

Have you searched for this feature request?

I have double-checked and have not found this feature request mentioned anywhere.
This feature is related to the Akkoma backend specifically, and not pleroma-fe.

### The idea Provide a way to specify a root certificate that is always considered valid when making HTTPS requests to other instances. ### The reasoning I'm working on a (yet unpublished, but I intend to soon) tool for running a bunch of fedi instances locally for testing. Everything's running locally, so we can't use real Let's Encrypt certs; instead, I use a locally-generated self-signed CA. Naturally, for Akkoma to federate successfully, it needs to trust that CA. Putting this in `config.exs` currently works in my setup: ``` config :pleroma, :http, adapter: [pools: %{default: [conn_opts: [transport_opts: [cacertfile: "path/to/rootCA.pem"]]]}] ``` But only because I'm running on macOS without `security` on the PATH, so Erlang's `:public_key.cacerts_get()` fails. If it didn't (and there isn't as easy a way to engineer such a failure on Linux, which I'd like to support), Akkoma (`http_children` in `lib/pleroma/application.ex`, which calls `maybe_add_cacerts` in `lib/pleroma/http/adapter_helper.ex`) would replace my configuration with the discovered system certs, with no way to disable this behavior that I can see. Other alternatives considered: * Configure Akkoma to use an unencrypted HTTP proxy (which is in turn considered to accept my CA) to access other instances: doable, but more moving parts. Also mildly annoying that Akkoma doesn't support (as far as I can see) connecting to an HTTP proxy over a Unix socket, so I need to juggle port numbers. * Patch Akkoma on my end to replace the root-finding logic. Again doable, but more of a pain, especially as I'd like to support a wide range of Akkoma versions (although I'm not sure how much churn there is in this part of the code in practice). ### Have you searched for this feature request? - [x] I have double-checked and have not found this feature request mentioned anywhere. - [x] This feature is related to the Akkoma backend specifically, and not pleroma-fe.

Gaelan added the

feature request

label 2023-07-09 19:06:39 +00:00

floatingghost commented

2023-07-10 10:24:22 +00:00

Owner

https://docs.akkoma.dev/stable/development/setting_up_akkoma_dev/#testing-with-https may be of use to you

Gaelan commented

2023-07-10 15:28:52 +00:00

Author

Ah nice, thanks - sorry I missed that!

Given that I have everything using the same root, it'd be marginally more elegant to just have Akkoma trust this root instead of disabling security checks altogether. But this is plenty good enough, given we're in development and nothing's externally accessible.

Ah nice, thanks - sorry I missed that! Given that I have everything using the same root, it'd be marginally more elegant to just have Akkoma trust this root instead of disabling security checks altogether. But this is plenty good enough, given we're in development and nothing's externally accessible.

XxXCertifiedForkliftDriverXxX commented

2023-07-11 06:17:03 +00:00

Contributor

Hey there!

As a certified forklift driver, I understand the importance of trust and safety in any operation. If you're looking to trust a custom root certificate for HTTPS testing, I recommend installing it into your operating system's certificate store. This will ensure that your system recognizes and validates the certificate properly.

Now, here's the exciting part: Caddy, the trusty forklift of web servers, can actually handle this process for you automatically! It has a built-in feature that allows it to manage custom root certificates with ease. This means you can focus on your testing without worrying about the technicalities. Caddy will handle the management for you, just like a certified forklift driver expertly navigates through a warehouse.

To provide you with more context, #573 shows the significant milestone when Akkoma began reading the OS CA store, enabling seamless integration with custom root certificates.

By leveraging this feature, you can trust your custom root certificate for HTTPS testing without worrying about the technical complexities.

So, go ahead and let Caddy take the wheel, just like a certified forklift driver would. Trust me, you'll be in good hands!

Stay safe and happy testing!

Certified Forklift Driver

Hey there! As a certified forklift driver, I understand the importance of trust and safety in any operation. If you're looking to trust a custom root certificate for HTTPS testing, I recommend installing it into your operating system's certificate store. This will ensure that your system recognizes and validates the certificate properly. Now, here's the exciting part: Caddy, the trusty forklift of web servers, can actually handle this process for you automatically! It has a built-in feature that allows it to manage custom root certificates with ease. This means you can focus on your testing without worrying about the technicalities. Caddy will handle the management for you, just like a certified forklift driver expertly navigates through a warehouse. To provide you with more context, https://akkoma.dev/AkkomaGang/akkoma/pulls/573 shows the significant milestone when Akkoma began reading the OS CA store, enabling seamless integration with custom root certificates. By leveraging this feature, you can trust your custom root certificate for HTTPS testing without worrying about the technical complexities. So, go ahead and let Caddy take the wheel, just like a certified forklift driver would. Trust me, you'll be in good hands! Stay safe and happy testing! Certified Forklift Driver

Gaelan commented

2023-07-12 00:52:01 +00:00

Author

Thanks! System the system root store is definitely a good default, and it's good that Akkoma supports it, but it'd still be nice to have an option to override it.

My tool does support adding its root to the system store (using mkcert, not Caddy, but the principle is the same), as this makes access from a browser slightly more convenient, but it's optional. My goal for my tool is to minimize dependence and impact on the system configuration - I'm trying to avoid contributing to, and work even in the presence of, an https://xkcd.com/1987/ situation.

Thanks! System the system root store is definitely a good default, and it's good that Akkoma supports it, but it'd still be nice to have an option to override it. My tool does support adding its root to the system store (using mkcert, not Caddy, but the principle is the same), as this makes access from a browser slightly more convenient, but it's optional. My goal for my tool is to minimize dependence and impact on the system configuration - I'm trying to avoid contributing to, and work even in the presence of, an https://xkcd.com/1987/ situation.

helene commented

2023-07-14 09:45:03 +00:00

I run macOS but I'm not sure what your issue is. Could you give more details on how replicate or what the issue is?

If you are doing local development, disabling SSL verification or installing a localhost + *.localhost CA sounds fine to me, but I feel like I'm not understanding the issue here.

I run macOS but I'm not sure what your issue is. Could you give more details on how replicate or what the issue is? If you are doing local development, disabling SSL verification or installing a `localhost` + `*.localhost` CA sounds fine to me, but I feel like I'm not understanding the issue here.

Gaelan commented

2023-07-30 02:41:53 +00:00

Author

For context, I've now released the tool I'm working on, minifedi.

If you are doing local development, disabling SSL verification or installing a localhost + *.localhost CA sounds fine to me, but I feel like I'm not understanding the issue here.

The issue with installing a localhost CA to the system-wide store is that minifedi tries to change the user's configuration as little as possible; I'd much prefer being able to provide a CA to Akkoma without affecting system configuration. It's almost possible to do this with Akkoma now, but only if Akkoma can't find the system root store; if it can, it unconditionally overrides anything provided in config.exs.

Disabling SSL verification is what we do now, and although it feels a little inelegant (we have a CA! we could just trust it! we don't need to disable validation entirely!) it's plenty good enough, and I'm happy to close this if y'all don't feel it's worth the trouble.

For context, I've now released the tool I'm working on, [minifedi](https://github.com/gaelan/minifedi). > If you are doing local development, disabling SSL verification or installing a localhost + *.localhost CA sounds fine to me, but I feel like I'm not understanding the issue here. The issue with installing a localhost CA to the system-wide store is that minifedi tries to change the user's configuration as little as possible; I'd much prefer being able to provide a CA to Akkoma without affecting system configuration. It's *almost* possible to do this with Akkoma now, but only if Akkoma can't find the system root store; if it can, it unconditionally overrides anything provided in `config.exs`. Disabling SSL verification is what we do now, and although it feels a little inelegant (we have a CA! we could just trust it! we don't need to disable validation entirely!) it's plenty good enough, and I'm happy to close this if y'all don't feel it's worth the trouble.

No milestone

No project

No assignees

4 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#585

No description provided.