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:

docker-php/src/fpm-apache/etc/apache2/sites-available/000-default.conf

Lines 88 to 90 in 8b02690

	SSLEngine on
	SSLCertificateFile /etc/ssl/web/ssl.crt
	SSLCertificateKeyFile /etc/ssl/web/ssl.key

Same with NGINX:

docker-php/src/fpm-nginx/etc/nginx/sites-available/default

Lines 55 to 56 in 8b02690

	ssl_certificate /etc/ssl/web/ssl.crt;
	ssl_certificate_key /etc/ssl/web/ssl.key;

🤔 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];

Loading

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];

Loading

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: #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: #59 (comment)

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.