Depending on this port has a few issues:
* It is not clear why a documentation generation system depends on this port
* It pulls in the entire tree for Perl
* FreeBSD now has certctl(8) managed trust store which makes ca_root_nss obsolete
* Pulling it causes this issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256902
Consider removing this port or make it configurable because cert management is a admin's task and not a port one's.
- Nature of requirement for ca_root_nss. Possible workaround?
- UX considerations for OPTIONAL ca_root_nss (in particular, disabled case)
- Alternative root cause resolutions
Note; while cert management isn't a ports domain, the default and out of box experience with respect to validation of remote servers is. There's an entire history of bug and user reports going back a long way  (among others), and we still don't cover all the bases.
(In reply to Kubilay Kocak from comment #1)
While I understand the out of the box exprience, but since certctl(8) is there, there is very little need for ca_root_nss or I simply don't understand why it is still required. I expect every OpenSSL aware application to set default verification paths unless it is overridden by some means.
I did a test run for our base ports with and without ca_root_nss on sphinx. I am from 120 packages down to 60 just because perl is out of the game.
(In reply to Michael Osipov from comment #0)
That was added in bug 212049.
Sphinx can pull some external bits.
Just for the record, when Sphinx can't fetch something, sometimes it does not break the build, but the doc output is changed/incomplete.
I'm not saying we can't remove it, but we need to test it carefully.
(In reply to Danilo G. Baio from comment #3)
By reading the issue you mentioned, this boils down to the same problem I have discussed with Kubilay over and over again, Python and/or urllib3 simply don't use the default location for the system cert store. See
* Bug 230414