Just got around to testing locally. I downloaded the most recent release artifact from my PR locally and instead of running the following in my dockerfile:

RUN curl -1sLf 'https://dl.cloudsmith.io/public/symfony/stable/setup.deb.sh' | bashRUN apt install -y symfony-cli

I substituted it with:

COPY data/core-backend/custom-symfony-binary.zip /tmp/custom-symfony-binary.zipRUN cd /tmp && unzip /tmp/custom-symfony-binary.zip -d /tmpRUN cd /tmp && tar -xvzf /tmp/symfony-cli_linux_amd64.tar.gzRUN mv /tmp/symfony /usr/local/bin/symfony

With the custom binary installed, I ran:

symfony server:ca:install --ips="192.168.1.4,localhost,127.0.0.1,::1"

Which produced a certificate with the 4 IPs listed correctly:

I tested without the ips flag specified and got an error, so marking as draft while I figure that out.

Ready for review but could use an additional test, see remaining section below

I resolved the issue and repeated my build process to generate a cert without the flag being set and produced the following cert:

Use case

My use case for this mostly stems from using a separate devices to host and access my dev environments. I'm exploring progressive web app related work, so the baked in path for https in a single command was very nice. Only issue is that accessing the site from an external client instead of localhost will generate a cert error since it's not being served over a valid ip. With this PR, I can add the additional IP to resolve the cert error to simply a cert authority error, which can be resolved with adding the cert locally.

I'm unsure if this functionality is really applicable to many or best practice. Some conversation on that wouldn't hurt, but this achieves what I need it to.

Remaining

I'm a little unfamiliar with go, but if someone could point me to where theserver:ca:install command is being tested during the release runner, I could add an additional test case to test with the ips flag set.

The fruits of my labor - a valid service worker served over https from another computer local on the network running a docker container running symfony server.

I’m not sure I would recommend adding the certificates we generate on another system that the local system where it has been generated.

Also, thedefault.p12 certificate is used by default for all instances of the Symfony CLI so removinglocalhost and127.0.0.1 can lead to unexpected issues.

Additionally, the remote IP can change at any time, with this implementation it means we need to make possible to regenerate it when needed.

Finally, supporting this inserver:ca:install means it also needs to be supported inlocal:server:start.

IF we follow this path I think I would rather generate a certificate on the fly based on the listenIP to avoid any conflicts or user errors.

However, I might have a solution for you: the HTTPS proxy usage seems to cover your use case as it’s reachable on other IPs and the certificate generation based on DNS names means no issue with IP change. would that work for you?

@ramity did you happen to have time to consider the alternative I mentioned last?