Mac OS Catalina invalidates virtual host certificates

[tmort]

See Summary for a temporary fix for Catalina users

ISSUE TYPE

• Bug Report

OS / ENVIRONMENT

1. Host operating system and version: Mac OS Catalina 10.15
2. (Windows) Native Docker or Docker Toolbox: N/A
3. Docker version: Docker version 19.03.2, build 6a30dfc
4. Docker Compose version: docker-compose version 1.24.1, build 4667896b
5. (Linux) Is SELinux enabled?: N/A
6. What git commit hash are you on?: MASTER

SUMMARY

In Mac OS Catalina, Certificates are expected to not have a valitidy period of more than 825 days. This was first mentioned in issue #622 by @science695. Any certificates that are issued past July 1st, 2019 fall under this and will display a certificate error.

The issue is how devilbox is generating certificates. It uses a tool called cert-gen (also by @cytopia). In this tool, a validity period of 10 years (3650 days) is set, and every time a certificate (or the certificate authority) is generated in devilbox, that value is used.

Quick and Temporary fix

In order to get this working, I manually changed the cert-gen and ca-gen files found in the httpd docker container.

Backup your files and do this at your own risk.

1. docker-compose exec httpd bash -l
2. I installed an editor to edit the files (vim) apt-get update && apt-get install vim
3. cd /usr/bin/
4. Edit cert-gen file, line 11 to read DEF_DAYS=800
5. Edit ca-gen file, line 11 to read DEF_DAYS=800
6. Regenerate your vhost by renaming the directory or restarting devilbox (https://devilbox.readthedocs.io/en/latest/vhost-gen/customize-specific-virtual-host.html#rename-project-directory)

Example of what happens

When devilbox generate a virtual host, it uses the OpenSSL command based on the cert-gen and ca-gen scripts. By looking at the devilbox logs docker-compose logs php -f we can see that when a virtual host is renamed, the certificate is issued like this:

httpd_1 | $ openssl x509 -req -extensions v3_req -extfile <(printf '[ req ]\nreq_extensions = v3_req\n[ v3_req ]\nsubjectAltName=DNS.1:myvhost.loc,DNS.2:*.myvhost.loc\n') -days 3650 -in /etc/httpd/cert/mass/myvhost.loc.csr -CA /ca/devilbox-ca.crt -CAkey /ca/devilbox-ca.key -CAcreateserial -out /etc/httpd/cert/mass/myvhost.loc.crt

Note the parameter -days is set to 3650 above. Once you make the changes to your cert-gen file as noted above and regenerate your virtual host, you should see something like this:

httpd_1 | $ openssl x509 -req -extensions v3_req -extfile <(printf '[ req ]\nreq_extensions = v3_req\n[ v3_req ]\nsubjectAltName=DNS.1:myvhost.loc,DNS.2:*.myvhost.loc\n') -days 800 -in /etc/httpd/cert/mass/myvhost.loc.csr -CA /ca/devilbox-ca.crt -CAkey /ca/devilbox-ca.key -CAcreateserial -out /etc/httpd/cert/mass/myvhost.loc.crt

As you can see above, the -days parameter has been modified to 800.

STEPS TO REPRODUCE

1. Create a virtual host.
2. Attempt to visit virtual host via HTTPS
3. You'll see a certificate error.

EXPECTED BEHAVIOUR

1. Create a virtual host.
2. Attempt to visit virtual host via HTTPS
3. Virtual host renders via HTTPS.

ACTUAL BEHAVIOUR

1. Create a virtual host.
2. Attempt to visit virtual host via HTTPS
3. You'll see a certificate error.

OTHER INFORMATION

Additional Reading

• Docker entrypoint file that shows the use of ca-gen and cert-gen in devilbox
• Original issue
• Apples requirements for Certificates
• While not directly linked to Devilbox, this issue is what first caused me to look at how the certificate was being issued and ultimately lead me to the solution

[smagnaschi]

Same exact problem. The alternative solution works until the containers are recreated. Is there a way to keep the change even when the containers are being re-built?

[tmort]

@smagnaschi I was having the same issue but was able to create a workaround using the docker-compose.override.yml. Note: This is only if you are using apache-2.4. If not, the fix outlined below does not work.

Place this docker-compose.override.yml file in the root of your devilbox installation, then restart devilbox. Once restarted, you should be able to run docker container list and see that there is a new image called sixfoot3/docker-apache-2.4:1.0. This is my image that I've put up on Docker Hub and forked from the original here. The only change in this version is pointing to my custom version of the cert-gen and ca-gen files in my forked repository of the CA-Gen script.

This should rebuild without issue and you should always have the correct certificate -days marker set using the above override. To remove it (and go back to normal), just delete the override file from the root of your devilbox installation.

[smagnaschi]

Perfect (for now)! Let's hope that this will be fixed for good.

[tmort]

Definitely not a permanent solution, but it'll help anyone who's running Catalina and has this issue.

[tmort]

Update: Smoother and more reasonable fix.

The editing of the core ca-gen and cert-gen libraries were unnecessary. I have amended my version of the docker-apache-2.4 library here to allow Devilbox users to set the validity period of their SSL Certificates via the .env file.

Steps:

1. $ cd /path/to/your/devilbox/install and stop Devilbox.
2. Update docker-composer.override.yml to the latest version. Note lines 9 and 53 have been updated. Eventually, line 53 may make it's way into the official Devilbox build.
3. Update .env file to include the following line, preferably at the bottom: SSL_VALIDITY_PERIOD=799. You can change 799 to whatever value you want the certificate to be set.
4. $ docker pull sixfoot3/docker-apache-2.4 This pulls the latest version of the custom Devilbox HTTPD that includes the ability for the variable set above to populate the cert-gen command (cert-gen ... -d 799 ...).
5. Start Devilbox again.

Ways to confirm the changes worked

• docker-compose logs -f and look for openssl x509 -req .... Further down on that line you will find -d 799 or whatever you set as your SSL_VALIDITY_PERIOD. NOTE: If you see 802, that means you did not set your .env file correctly (802 is the default defined by docker-compose.override.yml).
• Visit a virtual host (you may have to regenerate your virual host) and check the expiration date on your SSL.

Where do we go from here?

I am going to create a pull request at the docker-apache-2.4 repository and if @cytopia pulls it into the repository, step 2 above will no longer be required and only step 3 will be needed to set your validity period.

[nicolabeghin]

thanks @tmort workaround works perfectly!

[cytopia]

Will be fixed here: #647