Generate valid x509v3 Certificate

[brody192]

Main change -

• Updates init-ssl.sh to generate valid x509v3 certificates, previously it was generating v1 certificates and that was not compatible with rustls, Two community members have confirmed the changes made here worked, Alex and Milo.

Other changes -

• Updates wrapper.sh with these changes -
  • Detect if the current certificate is not v3 and regenerate it if so upon redeployment.
  • Detect if the current certificate will or has expired and regenerate it if so upon restart or redeploy.
  • Detect if the database was previously initialized without a certificate and generates a new certificate. Useful when going from postgres:latest to this image.
• Move the init-ssl.sh script back into the docker-entrypoint-initdb.d directory so that the database is first initialized and then the certificates are generated, otherwise there would be no postgresql.conf file to enable ssl on.
• Set the -e flag on the wrapper.sh and init-ssl.sh scripts so they exit if any command happens to fail, as i believe it would be better to fail than to risk starting the database without certificates.
• Updates the actions to use new versions of the docker action scripts.

Miscellaneous changes -

• Use --chmod=755 when copying in scripts to set the execution permissions vs doing chmod +x as another RUN command.
• Spelling

[melissa-hale]

@brody192 this looks 🔥

~just curious though if you tested to make sure the init-ssl script only runs when the conditions are met?~

~i had moved it out of the docker-entrypoint-initdb.d/ dir because (I think) the postgres image will execute anything in that directory on startup.~

ignore above 😄 -> https://hub.docker.com/_/postgres#:~:text=Warning%3A%20scripts%20in%20/docker%2Dentrypoint%2Dinitdb.d%20are%20only%20run%20if%20you%20start%20the%20container%20with%20a%20data%20directory%20that%20is%20empty

[brody192]

Yep, additionally I have tested the added logic in wrapper.sh by both deploying the current postgres-ssl based template and a template that deploys from postgres:16 and then replacing the source image with my image I built in my fork, in both tests the correct logic is triggered and either the invalid cert is regenerated or a cert is generated if one doesn't exist. The logic for the expired certificate also works as I tested that by deploying with SSL_CERT_DAYS set to 20, upon the next deploy it regenerated them, still with 20 days but it was proof the logic worked.