Consider adding FiloSottile/mkcert

[ailequal]

I recently needed to self signed a few certs. After some digging, I chose this library, which seems pretty good to me. Can we consider adding it to the provisioner?

Yes I know that we can manually generate them with openssl, but mkcert still superior in my opinion.

[stickgrinder]

I second this idea. This is a long-due task that we have discussed a couple of times already but have never implemented.

Having a strategy for a local development certificate is very useful to me.
Besides installing the tool at provisioning time, documenting its desired use in the playbook is paramount to ensure everyone adheres to the same practices.

[ailequal]

Regarding this library, I can testimony that it works pretty well with Dinghy. A few days ago I've submitted a PR for ensuring the certs supports with it.

Basically once mkcert is installed on the machine (pretty easy setup, just follow the repository documentation), all you have to do is:

# replace hello.loc with your desired domain
mkcert -key-file ~/.dinghy/certs/hello.loc.key -cert-file ~/.dinghy/certs/hello.loc.crt hello.loc

At that point, you'll need to restart the dinghy container (just do run-dinghy-proxy from our scripts) and you're good to go!
(Yes, this means that each time you modify anything inside the ~/.dinghy/certs path you have to restart dinghy, but luckily it should not be that frequent).

I also tried to replicate the setup with dnsdock, but sadly I failed (but it shouldn't matter that much, since we are moving to dinghy completely).

[stickgrinder]

@ailequal since dnsdock is a resolver, not a proxy, it makes sense that it doesn't have to do with certs. In that case, I guess the certs configuration should be done at pkg level, since the nginx (or other ingress) containers should be aware of them and force https redirects.

@paolomainardi what's your take on that? @ailequal implementation relies on Dinghy as a certificate provider. Is it worth doing the extra step and baking it into the packages?