I didn't know what category to put this question under-- Issuance Tech seemed like it might fit because I get staging and prod certificates just fine. They seem to be installed on the server properly as well as they can be...
When I am doing infrastructure as code work-- I am able to add "--staging" to my certbot command and redeploy my dev servers upon significant changes-- which includes a staging certificate on deployment for freestanding single instances.
But, the dev machines are stopped in their tracks as my browser stops me from seeing if the changes worked (or if changes broke things higher up...) via selenium and manual browsing. The staging cert isn't really for browsing-- but I'll hit limits if I use production...
I believe I can tell my browser (that I only use for testing my dev site with dummy accounts) to implicitly trust a cert from the letsencrypt staging CA-- how do I do that?
**When I was searching for my question already asked, I came across this post that says how to get certain certs related to the staging server... (it may come in handy answering the question)
(Also, it seems like it might be in my best interest to use a self-signed and temporarily trust it-- is that the solution?)
As you mention, you don’t want to add the staging root to your daily-use browser, since we hold our staging environment to a lower standard than our production environment, and you want would put yourself at risk for MitM by certificates issued against the staging environment.
It is possible to create different profiles in Firefox, and I believe you can add a trust anchor (root) to one profile but not another. However, I’m not positive of that. I know that NSS does keep some state outside of the browser profile mechanism. With some testing you could be sure - the add certificate UI is under Preferences > Security > Advanced, I think.
However, I think a better mechanism would be to use Firefox’s “add an exception” mechanism with a self-signed certificate on your dev sites.
We used to use the test-ca.pem (“happy hacker fake CA”) and test-ca.key from the public Boulder repo for staging, so yes, at that time trusting staging in your browser would have been an exceptionally bad idea!
We have since generated a new certificate just for staging, called “Fake LE Root X1.” We did this not to encourage trusting it (don’t trust it!), but because we wanted to start having our staging environment submit to Google’s testtube CT log so we’d have a more realistic staging environment. The operators of testtube asked that we use a root whose private key was not public, so that random strangers couldn’t spam their log.
Otherwise, the above quote is quite a understatement 
