Repository navigation
mkcert fails to install certificates in browser databases #39
Description
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
- Set up DDEV project in GitHub Actions with ubuntu-24.04
- Run Nightwatch tests from host against DDEV site
- Observe SSL certificate errors in browser
- 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:
- Detection step: Check if browser databases exist
- Initialization step: Start browsers briefly to create databases if missing
- 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 ™️.
Activity
rfay commentedon Aug 6, 2025
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 commentedon Aug 6, 2025
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 commentedon Aug 6, 2025
mkcertactually says when installing into the browser store that you have to restart the browser, but that hasn't been my experience.mxr576 commentedon Aug 6, 2025
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 commentedon Aug 6, 2025
I would guess that in CI context, the browser has never been run, thus its CA database has never been created, thus
mkcertcan't install into it.mxr576 commentedon Aug 6, 2025
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 commentedon Aug 6, 2025
jonaseberle commentedon Oct 1, 2025
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 -installbut I somehow found out that this works, too:It might even work to start the Github runner browsers with
CAROOT=/var/lib/docker/volumes/... chromium-browserpointing to the actual filesystem path of that volume? Or another location where themkcert -installfrom 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 commentedon Oct 28, 2025
I think it did not and it worked smoothly until the fix for #42 got merged, because that fix also made
certutilunavailable on GHA - if it would be available (installed viaapt) 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
certutilavailable 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 commentedon Oct 28, 2025
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 commentedon Nov 4, 2025
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:
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.
jonaseberle commentedon Nov 18, 2025
Our tests show that the certificate could not be added.
It seems initializing the certificate stores by starting the browsers is necessary if you want to use the runner's browsers with https://.
Doing that as part of our action would be a performance problem again. We can add a hint in the README if you want to.
mxr576 commentedon Nov 18, 2025
Are you sure? Initializing browser's security db takes 21s. That is not a lot.
Maybe we can also start that as a background task at the very beginning and spare some time with that. But probably I would only try this approach if starting browsers has actual impact on billing. I do not see that at this moment.
jonaseberle commentedon Nov 18, 2025
It is an edge use case. It takes time and it is a bit hacky (starting, then stopping browsers), so I prefer letting people do that in their workflows.