After running dscreate (where it creates self sign certs) I see this error:
[21/Apr/2018:23:58:14.354060715 -0400] - WARN - Security Initialization - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8162 - The certificate issuer's certificate has expired. Check your system date and time.)
We don't do anything related to time in the cacreate calls, so this sounds like an issue on your test system's clock perhaps? If you can, can you provide the CA cert content in ascii, and the system time on your machine?
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
I'll get to this tomorrow, but its my work laptop. Everything should be in order...
Looks like the CA cert that was generated had an expiration date of March 15.
[root@localhost slapd-TLS]# date Wed Apr 25 12:40:50 EDT 2018 [root@localhost slapd-TLS]# certutil -d . -V -n Self-Signed-CA -u Y certutil: certificate is invalid: Peer's Certificate has expired. [root@localhost slapd-TLS]# certutil -L -d . -n Self-Signed-CA Certificate: Data: Version: 3 (0x2) Serial Number: 00:ac:5a:df:f1 Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C= AU" Validity: Not Before: Mon Jan 15 21:07:13 2018 Not After : Thu Mar 15 21:07:13 2018 ...
FYI Server cert looks good:
# certutil -L -d . -n Server-Cert Certificate: Data: Version: 3 (0x2) Serial Number: 00:ad:55:da:de Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: "CN=ssca.389ds.example.com,O=testing,L=389ds,ST=Queensland,C= AU" Validity: Not Before: Wed Apr 25 16:34:06 2018 Not After : Wed Jul 25 16:34:06 2018
Okay the problem was this directory:
/etc/dirsrv/ssca
I guess we store the CA cert here and just reuse it forever.
Currently lib389 uses a 2 month expiration for all its certs. I think in general we should up this to a year (or even 10 years?). We should also check if the CA cert is expired before using it for new instances.
We should also make the validity period configurable at creation time (default to one year):
These functions should accept the validity time in months
create_rsa_ca() create_rsa_key_and_csr()
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.0
Metadata Update from @spichugi: - Issue assigned to spichugi
I think we need to decide what we want from lib389 CLI tools here.
The first thing that we should keep in mind, in my opinion, is that the Self-Singed CA certificate is a temporary solution. The user should replace the certificates later. We should warn the user about it during the instance creation.
Other things that we can consider: 1. Add one more configurable option to dscreate setup.inf file so the user can set the validity period for Self-Singed CA certificate during the instance creation 2. If there are expired certs (or certs that will expire less than in 2 months) we need to reissue/update the certificates
And if we want to go even further with certificate managing in lib389 CLI, we can add the certificate information to the lib389 CLI status tool.
What do you think, guys? The decision should be made here. Should we go this far or should we stop earlier and provide the minimal functionality (change the default to 1 year and add the validity time parameter to the function)?
I think we need to decide what we want from lib389 CLI tools here. The first thing that we should keep in mind, in my opinion, is that the Self-Singed CA certificate is a temporary solution. The user should replace the certificates later. We should warn the user about it during the instance creation.
Agreed, but that doesn't mean we should force a short expiry time on the certs though.
Other things that we can consider: 1. Add one more configurable option to dscreate setup.inf file so the user can set the validity period for Self-Singed CA certificate during the instance creation
This was my previous suggestion so I still like it. :-p Make the default one year.
If there are expired certs (or certs that will expire less than in 2 months) we need to reissue/update the certificates
+1
And if we want to go even further with certificate managing in lib389 CLI, we can add the certificate information to the lib389 CLI status tool. What do you think, guys? The decision should be made here. Should we go this far
Yes, absolutely. lib389 is a tool set to help with all things LDAP. That includes certificate management. It's okay if it's redundant with certutil/openssl. I just prefer the one-stop-shop approach: one tool/api to do everything we need for 389 - even if that means we wrap other system tools into our CLI.
I agree with Mark. The intent of adding ssca was to help make things easier if someone wanted to run a self signed CA.
I think that it would be reasonable to extend the validity of this to 2 years.
However, the true cause of this issue is that we are not refreshing the SSCA between tests. I think the reason I did this was so that during debugging, I could extract user certs and re-use them between test runs of the instance without reprovisioning them.
So a proper fix might be when DEBUGGING != True, that ssca is removed in teardown. When debugging == True, then we leave it (and of course, the next test run will just keep reusing it until debugging != True)
Hope that helps,
Metadata Update from @spichugi: - Custom field reviewstatus adjusted to review (was: None)
https://pagure.io/389-ds-base/pull-request/49709
Merged PR #49709 to master as 809be53.
Metadata Update from @mhonek: - Custom field reviewstatus adjusted to ack (was: review) - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
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 issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2705
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.