Juju seems to be validating that the *keys* are valid strings that are alphanumeric, starting with a letter, etc. But we shouldn't be validating the contents of the key.
And the above code:
```
secret = self.charm.unit.add_secret(
    {"certificate": certificate.certificate},
    label=f"{LIBID}-{certificate.csr}",
    expire=self._get_next_secret_expiry_time(certificate.certificate),
)
```

In that code the key is just "label" which is absolutely valid, and AFAICT juju should not be validating the *value*.

The above error string:
ERROR juju.worker.uniter.context cannot apply changes: creating secrets: Regular expression is invalid: nothing to repeat

the first part about 'cannot apply changes' is happening here:
https://github.com/juju/juju/blob/4d6ece0f954a9071a567a7c828e3bb70e3228a94/worker/uniter/runner/context/context.go#L1700

which is an API call back to the controller for it to commit the current Uniter state including all the changes from relation-set/secret-add/etc.
the second part 'creating secrets' would be coming from the API Server:
https://github.com/juju/juju/blob/4d6ece0f954a9071a567a7c828e3bb70e3228a94/apiserver/facades/agent/uniter/uniter.go#L2818

which means the last part about 'Regular expression is invalid: nothing to repeat' would be coming from the call to: 
https://github.com/juju/juju/blob/4d6ece0f954a9071a567a7c828e3bb70e3228a94/apiserver/facades/agent/uniter/uniter.go#L2805
"u.SecretsManagerAPI.CreateSecrets"

None of our Regexes should ever include user generated content (we might run a regex over user content, but we should not compile user content *into* a regex that we run).

Googling around, it does appear that "nothing to repeat" will tend to happen if you do something like "\w++" the first + repeats one or more word characters, and the second one has "nothing to repeat".
And it seems plausible that base64 content could very easily end up with a ++ in it (though more frequent would be ==).

But looking at the call to CreateSecrets:
https://github.com/juju/juju/blob/4d6ece0f954a9071a567a7c828e3bb70e3228a94/apiserver/facades/agent/secretsmanager/secrets.go#L242


That does make a call to things like ParseURI, which does include 2 regexes (validUUID and secretURIParse)
https://github.com/juju/juju/blob/4d6ece0f954a9071a567a7c828e3bb70e3228a94/core/secrets/secret.go#L62

I still don't see a code path where we would be running a regex that includes user data.

That said, if you are running on Microk8s (as given in the description), I believe we use K8s to store the content, and we would be using a different SecretsManager (I'm not positive on this, Ian/Kelvin would need to confirm.)
But in that scenario, its plausible that the secret backend itself is doing something different.

looking at ParseURI, all the error returns are wrapped with a different error message except url.Parse(str) which has its error message returned directly with just errors.Trace()

going back up the stack, createSecret has a bare Trace() if the "OwnerTag" was invalid.
Or if there was a problem calling OwnerToken, ParseURI, CreateSecret.


The particular error string "Regular expression is invalid" is also unlikely to be one that is from Juju. That particular string doesn't exist in our codebase. And using play.golang.org to try out an invalid regex, I get:
	_, err := regexp.Compile(`\w++`)
https://go.dev/play/p/5E-CQKifk1u

error parsing regexp: invalid nested repetition operator: `++`

(In general, Juju does not use "Capitals in our error messages")

However, that could be a Mongodb failure:
https://stackoverflow.com/questions/73763685/how-to-search-for-a-substring-in-mongodb-which-starts-with

And I can get that error message here:
juju:PRIMARY> db.secrets.find({"_id": {$regex: "+ab"}})
Error: error: {
        "operationTime" : Timestamp(1717010376, 1),
        "ok" : 0,
        "errmsg" : "Regular expression is invalid: nothing to repeat",
        "code" : 51091,
        "codeName" : "Location51091",
        "$clusterTime" : {
                "clusterTime" : Timestamp(1717010376, 1),
                "signature" : {
                        "hash" : BinData(0,"Zl0kcQDGdDfbcujr1K33DBDskmk="),
                        "keyId" : NumberLong("7374437784712380421")
                }
        }
}

Note that I couldn't get it from '{$regex: "ab++"}', but if you start with a + it does fail with exactly that error message.