mkcert fails to install certificates in browser databases

[mxr576]

Thanks for this tool!

I am porting our current pipeline to DDEV where we have Nightwatch tests executed on the host. We use ubuntu-24.04 in our GHA and I was surprised that tests fail because Chrome opened by Nightwatch complains about certificate errors, then I found this in the logs:

Created a new local CA 💥

The local CA is now installed in the system trust store! ⚡️

ERROR: no Firefox and/or Chrome/Chromium security databases found

The local CA is already installed in Java's trust store! 👍

Environment

• GitHub Actions runner: ubuntu-24.04
• DDEV version: 1.24.7
• Testing framework: Nightwatch (running on host, not in container)
• Browser: Chrome/Chromium

Steps to reproduce

1. Set up DDEV project in GitHub Actions with ubuntu-24.04
2. Run Nightwatch tests from host against DDEV site
3. Observe SSL certificate errors in browser
4. Check GHA logs for mkcert installation errors

Expected behavior

SSL certificates should be properly installed and trusted by browsers

Actual behavior

mkcert reports "ERROR: no Firefox and/or Chrome/Chromium security databases found"

Proposed solution

The action could detect when browser security databases are missing and initialize them before running mkcert -install. This could be implemented as:

1. Detection step: Check if browser databases exist
2. Initialization step: Start browsers briefly to create databases if missing
3. Installation step: Run mkcert installation

Example implementation in the action:

# Initialize browser security databases if they don't exist
if ! find ~/.mozilla -name "cert9.db" 2>/dev/null | grep -q .; then
    timeout 10s firefox --headless --no-sandbox || true
fi

if ! find ~/.pki -name "cert9.db" 2>/dev/null | grep -q .; then
    timeout 10s google-chrome --headless --no-sandbox --disable-gpu || true
fi

# Now install certificates
mkcert -install

Alternatively, the action could provide an option to skip SSL certificate installation entirely for testing scenarios where it's not needed.

Impact

This affects teams using:

• GitHub Actions with ubuntu-24.04 (likely increasing as it becomes the default)
• End-to-end testing frameworks that run on the host (Nightwatch, Playwright, Cypress)
• SSL-enabled DDEV sites (which is the default)

The current workaround requires teams to either disable SSL verification in their tests or manually initialize browsers in their workflows, adding complexity and reducing the "just works" experience that DDEV aims to provide.

Current workaround

For now, teams can work around this by adding these steps to their workflow before DDEV setup:

- name: Initialize browser databases
  run: |
    # Start Firefox briefly to initialize its security database
    timeout 10s firefox --headless || true
    # Start Chrome briefly to initialize its security database  
    timeout 10s google-chrome --headless --no-sandbox || true
    
- name: Reinstall mkcert certificates
  run: |
    mkcert -install

Assuming that others could also run into this issue, I would suggest fixing certificate installation in this action somehow so it would just work ™️.

[rfay]

When browsers don't use the system CA... DDEV/mkcert tells you about it.

You can install the CA, but I'm not sure how to do it programmatically as you would need to do in this case. You can also use http instead of https. Or use a browser that respects the system CA.

More detail at https://ddev.readthedocs.io/en/stable/users/install/configuring-browsers/

[mxr576]

Yes, I have read that article, however it seems in case of Github Actions the only thing that is missing is initializing browser's trust store by starting them before mkcert runs. They are installed system wide the tradition way on Ubuntu just they are not recognized yet. After the initialization, mkcert works as usual.

[rfay]

mkcert actually says when installing into the browser store that you have to restart the browser, but that hasn't been my experience.

[mxr576]

It misses the browsers' security database, whatever that means... Those has to be created and mckert runs fine afterwards and no issues with certificats in installed browsers.

[rfay]

I would guess that in CI context, the browser has never been run, thus its CA database has never been created, thus mkcert can't install into it.

[mxr576]

Exactly, this is my assumption too and the reason why I am suggesting that this GH action should warrant that at least these two major browsers (when they are installed) has been executed before mkcert command runs so it could fulfill its purpose.

[mxr576]

[jonaseberle]

I am not sure what we should do here.

My background is that I never used the installed browsers that are supposedly installed (?) on Github runners. I always only used Selenium containers that I added to the DDEV project.
Here is a public example: https://github.com/dmind-gmbh/extension-cookieman/blob/master/.ddev/docker-compose.selenium.yaml – the Selenium containers get used by a composer script which can be triggered from a Github workflow.
By the way: This was my "initial" use case and the reason why I wanted a running DDEV on a Github runner ;)
I used to build custom Selenium containers including mkcert -install but I somehow found out that this works, too:

    environment:
      - CAROOT=/mnt/ddev-global-cache/mkcert
    volumes:
      - ddev-global-cache:/mnt/ddev-global-cache

It might even work to start the Github runner browsers with CAROOT=/var/lib/docker/volumes/... chromium-browser pointing to the actual filesystem path of that volume? Or another location where the mkcert -install from the DDEV installation was successful?

---

Isn't your fix of starting the browsers to initialize their databases taking too long? Or rather: Could those that need it just do it like you proposed without needed changes in our action? In that case we could add it to the README (We have a "Recipes" section for example). I think it is a valid use case and guidance could prevent some users from being frustrated that https:// → DDEV does not work in their headless browsers.

[mxr576]

Isn't your fix of starting the browsers to initialize their databases taking too long?

I think it did not and it worked smoothly until the fix for #42 got merged, because that fix also made certutil unavailable on GHA - if it would be available (installed via apt) then the performance issue would be back - so certificates for browsers are never installed anymore. Which is fine... ™️ I think we just need to educate consumers of this GHA that they should always reach the site on HTTP instead of HTTPS. (AFAIK this is what is also being done in your example https://github.com/dmind-gmbh/extension-cookieman/blob/3.1.4/Build/browserstack.codeception.yml#L13)

We could also try to make certutil available by default in Ubuntu images, but I have no real means and capacity to try to convince Runner image maintainers in https://github.com/actions/runner-images as long as HTTP just works.

So I think the potential next step here is a Recipe section update.

[jonaseberle]

It's this https://github.com/dmind-gmbh/extension-cookieman/blob/3.1.4/Build/local.codeception.yml (the other one is for the paid remote service Browserstack and the config is not up-to-date anyways so I should delete it).

A hint/recipe would help. It would be something like "The local browsers in the Github runner cannot be used with https:// because ... ."?

[mxr576]

WOW , WOW, WOW!

Somebody was reading minds at GH... actions/runner-images#13160

This change means that my previous recommendation have changed and I am back to original recommendation about fixing browser's certificate store update on with local certs on GH.

Additional context:

but I have no real means and capacity to try to convince Runner image maintainers in https://github.com/actions/runner-images as long as HTTP just works.

A test in our test suite started to fail on HTTP, the tested code accesses the clipboard and we assumed that due to built-in guards in browsers, this is caused by serving the page on HTTP. So if HTTPS is possible, it is better to use that in automated e2e tests as well.