Trust the DDEV mkcert CA, so tests can browse the project over HTTPS

[vever001]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem?

The add-on points the test runners at http://web, so the browser never needs to trust a certificate. That works for most projects.

Projects that must browse the real project URL are stuck. Ours is a Drupal multisite, where the hostname selects the site, so http://web cannot work and tests navigate to https://<project>-<site>.ddev.site. The browser does not trust DDEV's mkcert root CA, so every navigation lands on the Privacy error warning page instead of the site.

Describe your solution

Both pieces already exist, they are just not connected: the image ships /opt/bin/add-cert-helper.sh, and DDEV keeps the CA at mkcert/rootCA.pem in the ddev-global-cache volume, which the add-on does not mount.

Mount the volume in docker-compose.selenium-chrome.yaml:

services:
  selenium-chrome:
    volumes:
      - ".:/mnt/ddev_config"
      - "ddev-global-cache:/mnt/ddev-global-cache"

and import the CA from a post-start hook in config.selenium-standalone-chrome.yaml:

hooks:
  post-start:
    - exec: |
        if [ -f /mnt/ddev-global-cache/mkcert/rootCA.pem ]; then
          ALIAS=mkcert /opt/bin/add-cert-helper.sh -d /mnt/ddev-global-cache/mkcert >/dev/null 2>&1
          certutil -d sql:/home/seluser/.pki/nssdb -L 2>/dev/null | grep -q mkcert || echo "mkcert CA import failed"
        fi
      service: selenium-chrome

Projects staying on http://web are unaffected, they just get one more trusted CA in the test browser.

Describe alternatives

Adding --ignore-certificate-errors to the chrome args also works, but Chromium does not use its HTTP cache on connections with certificate errors, so it disables browser caching for the whole run. Every request is then a cold one, so anything involving caching is testing the wrong thing. Nothing errors, so it goes unnoticed.

Doing the import from post_install_actions does not work either: the NSS database resets whenever the container is recreated, so it would quietly stop taking effect after the next ddev restart.

Projects can carry the volume and the hook themselves, which is what we do today, but it needs knowing that add-cert-helper.sh exists.

Additional context

ALIAS defaults to SeleniumHQ and the helper deletes that nickname before adding, so without setting it the mkcert CA replaces the image's own certificate instead of adding alongside it.

The output is worth suppressing: the helper dumps the whole certificate on every start, and on a fresh container it also prints a SEC_ERROR_INVALID_ARGS from that delete-before-add step plus a rehash warning, none of which mean anything went wrong. Checking the database afterwards is a more reliable signal than the exit status, since the helper does not use set -e.

Hooks from config.*.yaml are appended to a project's own post-start hooks rather than replacing them, so shipping this in the add-on will not clobber anything a project already defines.

Tested with DDEV v1.25.3, add-on 2.2.1, selenium/standalone-chromium:4.28.1.

[weitzman]

Seems reasonable to me. A PR would be welcome. That way we get a look at tests passing.

[vever001]

PR created.
I eventually decided not to rely on /opt/bin/add-cert-helper.sh after all, and the PR calls certutil directly instead.

The nickname it assigns is not stable across image versions: 4.28.1 honours ALIAS and deletes that nickname before adding, so an import silently replaces the image's own certificate unless you set it, while 138.0 ignores ALIAS in favour of ${ALIAS_PREFIX}_$(basename $cert_file). It is also noisy and does not use set -e, so I would have had to suppress the output and check the database separately anyway.

A direct certutil -A is one line, silent and returns a meaningful exit code.

[vever001]

One more correction from the initial issue description: Multisite explains why we cannot use http://web: the container hostname matches nothing in sites.php, so no site is selected. It does not explain the certificate, since plain http://<project>-<site>.ddev.site works fine and needs no CA.

The certificate is needed simply because the tests in my project browse the project's own hostnames, which DDEV serves over https by default.

Sorry for the confusion. Let me know if you'd like me to rewrite the description.