KDM validity period starts before or close to the start of the signing certificate validity period

[Alex Asp]

I have installed today a test version of DOM 2.15.38. It failed to start due to a missing library.
So I went back to 2.15.37, made an encripted DCP and tried to create a DKDM for it
Then I got this message: KDM validity period starts before or close to the start of the signing certificate validity period, and no DKDM was written.

How bad thais is, and how do I overcome this "little complication"?

Thanks



Alex

[carl]

That's odd. Was there a version of DOM on that machine before you installed 2.15.38?

[Alex Asp]

Yes,

and went back to 2.15.37

[carl]

How long ago did you install the first DOM on that machine (roughly)? Can you email me the contents of

Code: Select all

/Users/you/Library/Preferences/com.dcpomatic

?

carl@dcpomatic.com

[carl]

Thanks. I take it you're making KDMs with a validity period starting about now? If so, you shouldn't be seeing that error. Let me have a quick look at a few things.

Also, what's the end time on the KDMs you are making?

[saftsuse]

Hm. I have the same problem now.

I made an encrypted DCP a few days ago, and today I upgraded to the 2.15.47.

Problem.
Opening the encrypted DCP, going to "Jobs" and "Make DKDM for dcpomatic"

When clicking "OK" I get this msg: KDM validity period starts before or close to the start of the signing certificate validity period.

Regards
Erik

[saftsuse]

So I can not make any DKDM, but I can make a KDM but not longer validy than until about 2028.
But I can open that KDM at an another computer, and there I can make KDM that last "forever"

something strange is going on my main computer after I updated.

Any way to fix this?

[Carsten]

I don't have that issue in 2.15.47 (OS X) when creating DKDMs.

Are you sure your date and time is correct on that machine?

Normally, this issue should only come up for a short time if you want to create (D)KDMs immediately after your first DCP-o-matic installation, and after some cases where upon start, you are requested to recreate the signing certificate (in previous versions). As a matter of fact, this is only a warning, and a (D)KDM should still be created. Unless there is a bug that only Carl can say something about.

Creating KDMs with very long validity windows is not a good idea. With current stable versions, DCP-o-matic certs are created with a validity window of 10 years. If you create KDMs with a longer validity, this could become an issue with some software or equipment already before the cert expires. Even some servers have quite limited cert validity, e.g. mid 2020s.

Set your computers date and time to current actual values, and recreate your signing certificate in prefs, I'd say. Another thing to try is to set your computers date two days late (to an earlier date), recreate the signing certificate, quit DCP-o-matic, correct your computers date to the current correct time, and try again.

edit: If I recreate my signing cert now (March, 9th) with 2.15.47, the new cert validity window is:
Valid From: March 1, 2020
Valid To: February 25, 2060

With 2.14.31, it was
Valid From: March 8, 2020
Valid To: March 4, 2030


So, that change in 2.15.x should really fix the issue - but only if you recreate the signing cert.


- Carsten

[Alex Asp]

No. I don't have that problem with date and time. I have gone to 2.15.47 since my first post and the problem persists.
What's even more puzzling is that stable versions (currently 2.14.26) produce DKDMs with no problem and they can be imported into KDM creator (2.15.47), and the KDMs it generate are working fine.

Looks like there are two separate copies of signing certificate on the machine and they are saved in different places. Recreating them doesn't save the problem.


Alex

[Carsten]

Did you check the validity timeframes of you signing certs?

e.g. paste the content of the file into the field here (export all certs individually before):

https://www.sslshopper.com/certificate-decoder.html

Again, If possible, trash your current config and all certs (backup prefs before), and recreate. Maybe there is some inconsistency in your cert tree.

The prefs for 2.14.x and 2.15.x are the same files.

Again, at least from my perspective, that warning should not hinder the creation of a (D)KDM - the issue itself is not (yet) an error.

- Carsten