ack

I'm not sure what your concern here is. The statement is true, we self-sign certs out of box and they really are only for evaluation.

I'd rather have the text updated to communicate better if you have some kind of concern here.

I'm not sure what your concern here is. The statement is true, we self-sign certs out of box and they really are only for evaluation.
I'd rather have the text updated to communicate better if you have some kind of concern here.

My concern is that an instance's DB is not an SSCA. Only the one in /etc/dirsrv/ssca is. And also that in case of an instance the directory contains whole lot of other files than just the cert DB's ones - should we describe them in the README.txt, too?

How should we rather handle this README.txt in the context of an instance? Update a presence of the file (with a different contents, of course) based on the state-dependent fact of whether the cert DB contains some self-signed cert signed by only our SSCA? -- I believe it is not feasible, not worth the effort. Another possible implementation would be to state within the README that the cert DB could contain a SSCA-signed cert, which is more confusing than useful.

If we would like to warn a user of using SSCA signed cert then that should be done in other places, like dsconf security warning, ns-slapd startup warning; dscreate should state it at the creation time loudly if it does not, yet.

ahh okay, I clearly missed that detail. Apparently I forgot that ssca uses a seperate database despite the fact I wrote that code ....

In that case there is nothing wrong with this then. I think that dsctl healthcheck is a better place to build on the back of @mreynolds' recent work if we want to alert to ssca usage. Dscreate I think is the wrong place, there is a LOT of information thrown at the user in the logs, so we shouldn't put it there unless we had dscreate emit a post-install checklist or something that admins should follow?

Anyway, in that case, ack from me.

@firstyear Your idea for healthcheck: #50759.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3790

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.