Auto-generated SSL should have an option to disable

[jaydrogers]

Current Behavior

Right now, SSL is automatically generated: https://github.com/serversideup/docker-php/blob/main/templates/fpm-nginx/etc/cont-init.d/10-generate-ssl

Expected Behavior

There should be an option to disable the SSL auto-generation.

Apply to:

• [ ] Apache (All PHP Versions)
• [ ] NGINX (All PHP Versions)

Steps To Reproduce

1. Pull the container
2. Start the container

Host Operating System

All

Docker Version

All

Anything else?

No response

[jaydrogers]

@fideloper: You're the one who proposed this feature. It makes total sense on why to have the option to disable. I have a few questions to bounce off you before I develop this:

If AUTO_GENERATE_SSL == false, how should that affect NGINX + Apache configs?

📕 Background

Apache is expecting some sort of SSL file to exist: https://github.com/serversideup/docker-php/blob/8b026906c15708cdd0684d42f5bdac0828f9db2d/src/fpm-apache/etc/apache2/sites-available/000-default.conf#L88-L90

Same with NGINX: https://github.com/serversideup/docker-php/blob/8b026906c15708cdd0684d42f5bdac0828f9db2d/src/fpm-nginx/etc/nginx/sites-available/default#L55-L56

🤔 Possible Solutions

Option A: Package default self-signed certificates for every image

The reason for "auto-generation" was to provide a little more security by not having private keys replicated across everyone's machine. I can provide a default one, but it would be interesting to hear thoughts from a security perspective.

I guess I could provide a default SSL certificate, but then default AUTO_GENERATE_SSL=true so it overwrites it in the default behavior?

Option B: Come up with some advanced logic for generation

There may be some ways where I could explore supporting no SSL or generate only if one does not exist? It might just get tricky with Apache and NGINX since their configs don't support advanced logic within them.

👉 Next steps

@fideloper: If you could share more of your use case, I would love to match what you're looking for 👍

[fideloper]

My use case was using it on Fly.io which doesn't do end-to-end encryption (terminates the SSL connection when it reaches Fly's proxy layer.

In that case, I just overwrote the nginx.conf file in sites-available.

Perhaps here you can have a default site and a default-ssl Nginx config and use Nginx (and Apache's) sites-available/sites-enabled configuration to just have the non-ssl config in place when that flag is set to false.

[jaydrogers]

This is brilliant and I will get an update for this soon. Currently working on a 2.0 release for these images, so once I get that stabilized I will get this added.

Thanks Chris!

[herpaderpaldent]

Maybe i am late to the party but i am using traefik as proxy. I don't need the ssl in anyway but do not need to adapt the nginx.conf either.

Either i am doing something wrong or have just terrible luck

[jaydrogers]

Nope, you're fine. I use Traefik too.

We're both using it like this right now:

graph TD;
    A[Traefik - SSL: Let's Encrypt] --> B[fpm-nginx - SSL: Self-signed];

We dont see any errors because Traefik is ignoring the self-signed certificate, but it still is "end-to-end" encryption.

What will change

If the user disables AUTO_GENERATE_SSL, then it will just do HTTP only for the (if they do not provide their own SSL).

graph TD;
    A[Traefik - SSL: Let's Encrypt] --> C{AUTO_GENERATE_SSL}
    C{AUTO_GENERATE_SSL} --> |true| B[fpm-nginx - SSL: Self-signed];
    C{AUTO_GENERATE_SSL} --> |false| D[fpm-nginx - HTTP only];

I will put some other logic once I have a moment to sit down and think about it, but I am leaning towards keeping AUTO_GENERATE_SSL = true by default.

You wont need to make any changes after this if it's working for you now. 👍

[jaydrogers]

Update: This is now ready for testing 🎉

Everything is ready for testing on our beta images.

What's new

I made a new variable called SSL_MODE.

There are three options:

1. Off: Use HTTP only
2. Mixed: Use HTTP + HTTPS
3. Full (default): HTTPS only. Redirect HTTP → HTTPS

Documentation

I have everything updated in the upcoming documentation: https://github.com/serversideup/docker-php/tree/dev#production-ssl-configurations

View the source

You can see how it works here: https://github.com/serversideup/docker-php/blob/dev/src/fpm-nginx/etc/s6-overlay/scripts/configure-ssl

When will this get deployed?

This will be deployed to "stable" once this branch is merged: https://github.com/serversideup/docker-php/pull/59

Any questions, thoughts, or feedback, let me know!

[jaydrogers]

This has been merged to stable 🎉 https://github.com/serversideup/docker-php#production-ssl-configurations

[dragonfire1119]

This has been merged to stable 🎉 https://github.com/serversideup/docker-php#production-ssl-configurations

This is a nice feature, and I appreciate your time on this project, but I wish it had been communicated how it could break my entire site and send it into a redirect loop. For a few hours, I looked at my CI process all the way down to the routes, trying to figure out what went wrong. I even looked through the Cloudflare settings to find the redirect loop. I'm not complaining; I just wish I'd known about it before making the change to my current image.

It is a simple environment change to set SSL MODE to mixed.

[jaydrogers]

Sorry dude, I didn't have any intentions on breaking anyone's site 😅

[jaydrogers]

I also hit "feature freeze" a month ago and didn't receive any complaints, so I figured it was safe to merge. I did a number of testing on my own sites and others helped as well: https://github.com/serversideup/docker-php/pull/59#issuecomment-1260146079

All my sites also did not experience the issue until I had one simple development thing happen this morning.

Setting SSL_MODE == mixed was my solution as well.

[dragonfire1119]

Sorry dude, I didn't have any intentions on breaking anyone's site 😅

It's all right, man! To be honest, I should have paid more attention to the repo for changes. I didn't look at this image when the redirect loop occurred because I did extensive testing before putting the image into production against my old image. So I looked elsewhere besides your image. Because I'm thinking it can't be this Docker image because it's so stable. LOL Now I have to figure out why my tests did not fail before they were put into production.

[jaydrogers]

Because I'm thinking it can't be this Docker image because it's so stable. LOL

LOL! Thanks for the compliments, that is definitely my goal.

Now I have to figure out why my tests did not fail before they were put into production.

Gotta love CI 😃 Other than CI, using something like Uptime Kuma might be advantageous to capture outages. CloudFlare's built-in tools might be a good soltution as well: https://blog.cloudflare.com/new-tools-to-monitor-your-server-and-avoid-downtime/

Moving forward

Few things that could help moving forward:

Watch the repo

You might have some interest watching the repo too. You can subscribe to my releases an pull requests if needed.

My idea for this repo: Coming up with a better versioning system

I want to be able to offer tagged versions for better stability, but I am contemplating on how that would work. For example, if I tag an image serversideup/php:8.1-fpm-nginx-v2.0.1, that's easy to do the first time, but it's weird for me to go back and keep the things like the Ubuntu packages updated.

I have to think on that one more and figure out how I am going to do that. I really like having the automated Ubuntu updates and I think it's good for the Internet to have them overall.

Sorry for the headache and thanks for using my PHP images!

[dragonfire1119]

Gotta love CI 😃 Other than CI, using something like Uptime Kuma might be advantageous to capture outages. CloudFlare's built-in tools might be a good soltution as well: https://blog.cloudflare.com/new-tools-to-monitor-your-server-and-avoid-downtime/

Yes, I use UptimeRobot to check. That's the only reason I knew it was down, but it was late at night because I expected the CI to release the updates working, but it didn't, so I learned that I need to release during the day so I can quickly revert it. But hopefully it won't happen again.

Watch the repo

You might have some interest watching the repo too. You can subscribe to my releases an pull requests if needed.

I'm watching the repo, but sometimes I get lost in all the notifications and get busy.

My idea for this repo: Coming up with a better versioning system

I want to be able to offer tagged versions for better stability, but I am contemplating on how that would work. For example, if I tag an image serversideup/php:8.1-fpm-nginx-v2.0.1, that's easy to do the first time, but it's weird for me to go back and keep the things like the Ubuntu packages updated.

I have to think on that one more and figure out how I am going to do that. I really like having the automated Ubuntu updates and I think it's good for the Internet to have them overall.

Sorry for the headache and thanks for using my PHP images!

I believe it is a good idea, but you risk having someone who does not update the versions and thus falls behind on security updates. So I guess it's a two-edged sword.

Could you make SSL MODE mixed the default?

Is there any particular reason you didn't?

[jaydrogers]

Could you make SSL MODE mixed the default? Is there any particular reason you didn't?

This could potentially be a very good idea.

I guess it was my "privacy focused mind" of "SSL ALL THE THINGS" just to ensure HTTP traffic was never accidentally leaked.

I opened up a discussion about this here: https://github.com/serversideup/docker-php/discussions/85

[dragonfire1119]

Could you make SSL MODE mixed the default? Is there any particular reason you didn't?

This could potentially be a very good idea.

I guess it was my "privacy focused mind" of "SSL ALL THE THINGS" just to ensure HTTP traffic was never accidentally leaked.

I opened up a discussion about this here: #85

I understand the security aspect, and I prefer to use SSL on everything;

I got everything to work on 443. Thank you for the suggestions, and I appreciate your time! Perhaps this is all a moot point and it should have been run on 443. Lesson learned!

[dragonfire1119]

@jaydrogers One last question: if all of the proxies are SSL enabled and this is the only thing listening on port 80 in our network, does the container listening on 80 make a difference?

[jaydrogers]

The container port does not make a difference.

Once it hits your proxy, only your proxy will need to be able to access the container port.

For example, we have:

graph TD;
    A[Traefik: 80 & 443] --> B[fpm-nginx - SSL: 443];