#49646 dscreate create expired CA Cert
Closed: wontfix 3 years ago Opened 4 years ago by mreynolds.

Issue Description

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

4 years ago

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?

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

4 years ago

Metadata Update from @spichugi:
- Issue assigned to spichugi

4 years ago

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.

  1. 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)

3 years ago

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)

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.

Metadata