9 Jun
2018
9 Jun
'18
8:48 p.m.
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
It's working on some of the auditoriums.
We got DSS200 and Cat. No. 745
11 Jun
11 Jun
9:51 a.m.
Hi Tobias,
That's an odd one. I'll put a message out onto the forums to see if
anybody knows what that actually means.
Do you have the same software versions running on the DSS200/Cat.745 in
all your auditoria?
Are you using DCP-o-matic's automatically-generated signing certificates?
(if you haven't imported your own certs, you will be).
Kind regards,
Carl
On Sat, 9 Jun 2018, Tobias Jingwall via DCPomatic wrote:
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
It's working on some of the auditoriums.
We got DSS200 and Cat. No. 745
12 Jun
12 Jun
4:19 p.m.
Hi!
I have been helping investigating this quite a bit. I think that one
of two (or both) things are happening:
1) DoM self-signed certificate chain is created with a validity time
stamp in the future. This could happen because either the system clock
on the machine which DoM runs on, or the media block secure clock is
out of sync. I don't know if there is anything we really can do about
this, apart from telling people that it is important to have accurate
clocks. Especially Dolby Cat745:s are notorious for drifting (usually
into the future though). The Cat745 clock in this particular case has
been verified as set accurately. Unfortunately I have so far been
unable to verify if system time on the system which DoM was run to
generate the content was set correctly.
2) uuid:s for DoM:s KDM:s are reused. Why I suspect that maybe DoM
incorrectly re-uses KDM uuid:s is because the Cat745 log below
referencing an ID from the KDM XML issued with the same id after this
log entry
From the Cat745 log (the clock is accurate and set to
UTC):
Jun 9 06:39:34 (none) daemon.info decoder: *KDM ***CHECK*** started*
Jun 9 06:39:34 (none) daemon.info decoder: Parsing KDM XML
Jun 9 06:39:34 (none) daemon.info decoder: KDM XML parse statistics
[w:0] - [e:0] - [f:0]
Jun 9 06:39:34 (none) daemon.info decoder: De-serializing KDM
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM id [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ] and CPL id
[urn:uuid:74ba48d5-eead-4326-8450-586eb352dacb ]
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM Certificate Chain
Jun 9 06:39:34 (none) daemon.err decoder: Certificate verification
failure: certificate is not yet valid sn:
/O=dcpomatic.com/OU=dcpomatic.com/CN=.dcpomatic.smpte-430-2.ROOT/dnQualifier=29lUqc7kxOCh6TkpwD9eOM9JBsg=
depth: 2
Jun 9 06:39:34 (none) daemon.info decoder: Destroying KDM [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ]
Jun 9 06:39:34 (none) daemon.info decoder: KDM validation failed: [
X509 certificate verification failed ] #CertFormatError
Jun 9 06:39:34 (none) daemon.info decoder: DEBUG: Check KDM completed
[#CertFormatError]
Excerpt from KDM 4576cbc1-62ef-4d99-967b-5b79be35344d XML:
<IssueDate>2018-06-09T19:31:57+02:00</IssueDate>
<Signer>
<ds:X509IssuerName>dnQualifier=Q0ZlUge6zK2OCaGcPnyDlP2Uo28=,CN=.dcpomatic.smpte-430-2.INTERMEDIATE,OU=dcpomatic.com,O=dcpomatic.com</ds:X509IssuerName>
<ds:X509SerialNumber>7</ds:X509SerialNumber>
</Signer>
<RequiredExtensions>
<KDMRequiredExtensions
xmlns="http://www.smpte-ra.org/schemas/430-1/2006/KDM">
<Recipient>
<X509IssuerSerial>
<ds:X509IssuerName>dnQualifier=xXoRSRkNkwROURqMrh3PRRPASfI=,CN=.DolbyDC-MFGCA-ARX-4,O=DC256.Cinea.Com,OU=DolbyMediaBlock</ds:X509IssuerName>
<ds:X509SerialNumber>584</ds:X509SerialNumber>
</X509IssuerSerial>
(...)
</Recipient>
(...)
<ContentKeysNotValidBefore>2018-06-09T14:11:00+02:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2018-12-16T19:13:00+02:00</ContentKeysNotValidAfter>
Excerpt from "openssl x509 -text" fort cert #7 from above:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = dcpomatic.com, OU = dcpomatic.com, CN =
.dcpomatic.smpte-430-2.INTERMEDIATE, dnQualifier =
Q0ZlUge6zK2OCaGcPnyDlP2Uo28=
Validity
Not Before: Jun 9 14:47:26 2018 GMT
Not After : Jun 4 14:47:26 2028 GMT
Subject: O = dcpomatic.com, OU = dcpomatic.com, CN =
CS.dcpomatic.smpte-430-2.LEAF, dnQualifier =
"Z8+acwErJf+bgd/b+4fPD1Mxpac="
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Best,
Mattias
On Mon, Jun 11, 2018 at 11:51 AM, Carl Hetherington via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Hi Tobias,
That's an odd one. I'll put a message out onto the forums to see if
anybody knows what that actually means.
Do you have the same software versions running on the DSS200/Cat.745 in
all your auditoria?
Are you using DCP-o-matic's automatically-generated signing certificates?
(if you haven't imported your own certs, you will be).
Kind regards,
Carl
On Sat, 9 Jun 2018, Tobias Jingwall via DCPomatic wrote:
--
-mattias
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
It's working on some of the auditoriums.
We got DSS200 and Cat. No. 745
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
11:05 p.m.
Hi Mattias,
Thank you for getting in touch. It's great to have some debugging done on
this!
The timing certainly looks wrong: it seems that at 6am on June 9th the
Cat745 is being given a certificate whose validity doesn't start until
3pm. Is that what you are seeing?
Perhaps we can backdate DoM's certificates a bit (or a lot) to reduce the
chance of this happening...
The KDM UUID re-use thing is worrying. Do you know which UUID we are
talking about here? Is it the AuthenticatedPublic MessageId or something
else?
I may be a bit slow to respond as I am away on holiday for a week from
tomorrow.
Thanks again,
Carl
On Tue, 12 Jun 2018, Mattias Mattsson wrote:
Hi!
I have been helping investigating this quite a bit. I think that one
of two (or both) things are happening:
1) DoM self-signed certificate chain is created with a validity time
stamp in the future. This could happen because either the system clock
on the machine which DoM runs on, or the media block secure clock is
out of sync. I don't know if there is anything we really can do about
this, apart from telling people that it is important to have accurate
clocks. Especially Dolby Cat745:s are notorious for drifting (usually
into the future though). The Cat745 clock in this particular case has
been verified as set accurately. Unfortunately I have so far been
unable to verify if system time on the system which DoM was run to
generate the content was set correctly.
2) uuid:s for DoM:s KDM:s are reused. Why I suspect that maybe DoM
incorrectly re-uses KDM uuid:s is because the Cat745 log below
referencing an ID from the KDM XML issued with the same id after this
log entry
From the Cat745 log (the clock is accurate and set
to UTC):
Jun 9 06:39:34 (none) daemon.info decoder: *KDM ***CHECK*** started*
Jun 9 06:39:34 (none) daemon.info decoder: Parsing KDM XML
Jun 9 06:39:34 (none) daemon.info decoder: KDM XML parse statistics
[w:0] - [e:0] - [f:0]
Jun 9 06:39:34 (none) daemon.info decoder: De-serializing KDM
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM id [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ] and CPL id
[urn:uuid:74ba48d5-eead-4326-8450-586eb352dacb ]
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM Certificate Chain
Jun 9 06:39:34 (none) daemon.err decoder: Certificate verification
failure: certificate is not yet valid sn:
/O=dcpomatic.com/OU=dcpomatic.com/CN=.dcpomatic.smpte-430-2.ROOT/dnQualifier=29lUqc7kxOCh6TkpwD9eOM9JBsg=
depth: 2
Jun 9 06:39:34 (none) daemon.info decoder: Destroying KDM [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ]
Jun 9 06:39:34 (none) daemon.info decoder: KDM validation failed: [
X509 certificate verification failed ] #CertFormatError
Jun 9 06:39:34 (none) daemon.info decoder: DEBUG: Check KDM completed
[#CertFormatError]
Excerpt from KDM 4576cbc1-62ef-4d99-967b-5b79be35344d XML:
<IssueDate>2018-06-09T19:31:57+02:00</IssueDate>
<Signer>
<ds:X509IssuerName>dnQualifier=Q0ZlUge6zK2OCaGcPnyDlP2Uo28=,CN=.dcpomatic.smpte-430-2.INTERMEDIATE,OU=dcpomatic.com,O=dcpomatic.com</ds:X509IssuerName>
<ds:X509SerialNumber>7</ds:X509SerialNumber>
</Signer>
<RequiredExtensions>
<KDMRequiredExtensions
xmlns="http://www.smpte-ra.org/schemas/430-1/2006/KDM">
<Recipient>
<X509IssuerSerial>
<ds:X509IssuerName>dnQualifier=xXoRSRkNkwROURqMrh3PRRPASfI=,CN=.DolbyDC-MFGCA-ARX-4,O=DC256.Cinea.Com,OU=DolbyMediaBlock</ds:X509IssuerName>
<ds:X509SerialNumber>584</ds:X509SerialNumber>
</X509IssuerSerial>
(...)
</Recipient>
(...)
<ContentKeysNotValidBefore>2018-06-09T14:11:00+02:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2018-12-16T19:13:00+02:00</ContentKeysNotValidAfter>
Excerpt from "openssl x509 -text" fort cert #7 from above:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = dcpomatic.com, OU = dcpomatic.com, CN =
.dcpomatic.smpte-430-2.INTERMEDIATE, dnQualifier =
Q0ZlUge6zK2OCaGcPnyDlP2Uo28=
Validity
Not Before: Jun 9 14:47:26 2018 GMT
Not After : Jun 4 14:47:26 2028 GMT
Subject: O = dcpomatic.com, OU = dcpomatic.com, CN =
CS.dcpomatic.smpte-430-2.LEAF, dnQualifier =
"Z8+acwErJf+bgd/b+4fPD1Mxpac="
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Best,
Mattias
On Mon, Jun 11, 2018 at 11:51 AM, Carl Hetherington via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Hi Tobias,
That's an odd one. I'll put a message out onto the forums to see if
anybody knows what that actually means.
Do you have the same software versions running on the DSS200/Cat.745 in
all your auditoria?
Are you using DCP-o-matic's automatically-generated signing certificates?
(if you haven't imported your own certs, you will be).
Kind regards,
Carl
On Sat, 9 Jun 2018, Tobias Jingwall via DCPomatic wrote:
--
-mattias
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
It's working on some of the auditoriums.
We got DSS200 and Cat. No. 745
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
22 Aug
22 Aug
12:42 p.m.
Hi all,
Sorry I dropped the ball with this... too many emails and too little time.
I'm still keen to get to the bottom of it!
1) DoM self-signed certificate chain is created with a
validity time
stamp in the future. This could happen because either the system clock
on the machine which DoM runs on, or the media block secure clock is
out of sync. I don't know if there is anything we really can do about
this, apart from telling people that it is important to have accurate
clocks. Especially Dolby Cat745:s are notorious for drifting (usually
into the future though). The Cat745 clock in this particular case has
been verified as set accurately. Unfortunately I have so far been
unable to verify if system time on the system which DoM was run to
generate the content was set correctly.
The chain should only be created when DCP-o-matic is first run on a
machine, so unless the clock was way out I think this should only happen
if a DCP is made soon enough after DCP-o-matic's initial install.
Maybe it's possible to set the validity period of DoM's certificates to
start before "now" as a partial workaround?
2) uuid:s for DoM:s KDM:s are reused. Why I suspect
that maybe DoM
incorrectly re-uses KDM uuid:s is because the Cat745 log below
referencing an ID from the KDM XML issued with the same id after this
log entry
I don't think I follow this, sorry. The log is validating 4576cbc1...
where is the re-use?
Thanks for getting in touch!
All the best,
Carl
From the Cat745 log (the clock is accurate and set
to UTC):
Jun 9 06:39:34 (none) daemon.info decoder: *KDM ***CHECK*** started*
Jun 9 06:39:34 (none) daemon.info decoder: Parsing KDM XML
Jun 9 06:39:34 (none) daemon.info decoder: KDM XML parse statistics
[w:0] - [e:0] - [f:0]
Jun 9 06:39:34 (none) daemon.info decoder: De-serializing KDM
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM id [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ] and CPL id
[urn:uuid:74ba48d5-eead-4326-8450-586eb352dacb ]
Jun 9 06:39:34 (none) daemon.info decoder: Validating KDM Certificate Chain
Jun 9 06:39:34 (none) daemon.err decoder: Certificate verification
failure: certificate is not yet valid sn:
/O=dcpomatic.com/OU=dcpomatic.com/CN=.dcpomatic.smpte-430-2.ROOT/dnQualifier=29lUqc7kxOCh6TkpwD9eOM9JBsg=
depth: 2
Jun 9 06:39:34 (none) daemon.info decoder: Destroying KDM [
urn:uuid:4576cbc1-62ef-4d99-967b-5b79be35344d ]
Jun 9 06:39:34 (none) daemon.info decoder: KDM validation failed: [
X509 certificate verification failed ] #CertFormatError
Jun 9 06:39:34 (none) daemon.info decoder: DEBUG: Check KDM completed
[#CertFormatError]
Excerpt from KDM 4576cbc1-62ef-4d99-967b-5b79be35344d XML:
<IssueDate>2018-06-09T19:31:57+02:00</IssueDate>
<Signer>
<ds:X509IssuerName>dnQualifier=Q0ZlUge6zK2OCaGcPnyDlP2Uo28=,CN=.dcpomatic.smpte-430-2.INTERMEDIATE,OU=dcpomatic.com,O=dcpomatic.com</ds:X509IssuerName>
<ds:X509SerialNumber>7</ds:X509SerialNumber>
</Signer>
<RequiredExtensions>
<KDMRequiredExtensions
xmlns="http://www.smpte-ra.org/schemas/430-1/2006/KDM">
<Recipient>
<X509IssuerSerial>
<ds:X509IssuerName>dnQualifier=xXoRSRkNkwROURqMrh3PRRPASfI=,CN=.DolbyDC-MFGCA-ARX-4,O=DC256.Cinea.Com,OU=DolbyMediaBlock</ds:X509IssuerName>
<ds:X509SerialNumber>584</ds:X509SerialNumber>
</X509IssuerSerial>
(...)
</Recipient>
(...)
<ContentKeysNotValidBefore>2018-06-09T14:11:00+02:00</ContentKeysNotValidBefore>
<ContentKeysNotValidAfter>2018-12-16T19:13:00+02:00</ContentKeysNotValidAfter>
Excerpt from "openssl x509 -text" fort cert #7 from above:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = dcpomatic.com, OU = dcpomatic.com, CN =
.dcpomatic.smpte-430-2.INTERMEDIATE, dnQualifier =
Q0ZlUge6zK2OCaGcPnyDlP2Uo28=
Validity
Not Before: Jun 9 14:47:26 2018 GMT
Not After : Jun 4 14:47:26 2028 GMT
Subject: O = dcpomatic.com, OU = dcpomatic.com, CN =
CS.dcpomatic.smpte-430-2.LEAF, dnQualifier =
"Z8+acwErJf+bgd/b+4fPD1Mxpac="
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Best,
Mattias
On Mon, Jun 11, 2018 at 11:51 AM, Carl Hetherington via DCPomatic
<dcpomatic(a)carlh.net> wrote:
Hi Tobias,
That's an odd one. I'll put a message out onto the forums to see if
anybody knows what that actually means.
Do you have the same software versions running on the DSS200/Cat.745 in
all your auditoria?
Are you using DCP-o-matic's automatically-generated signing certificates?
(if you haven't imported your own certs, you will be).
Kind regards,
Carl
On Sat, 9 Jun 2018, Tobias Jingwall via DCPomatic wrote:
--
-mattias
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
It's working on some of the auditoriums.
We got DSS200 and Cat. No. 745
_______________________________________________
DCPomatic mailing list
DCPomatic(a)carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic
1 Dec
1 Dec
4:03 p.m.
Hi!
Sorry for the late reply. I have no direct access to the created DCP
and the equipment used. I have just studied the logs.
On Wed, Aug 22, 2018 at 2:42 PM Carl Hetherington <cth(a)carlh.net> wrote:
Sorry, this was sort of a wild guess. I don't think this was ever the case.
Best,
Mattias
Hi all,
Sorry I dropped the ball with this... too many emails and too little time.
I'm still keen to get to the bottom of it!
Maybe a warning or a note in the manual is enough? Some media block's
secure clocks are prone to be really off. Especially the Dolby Cat.745
can be upt to 1,5 hours off in "normal" operation. The units I have
seen with the secure clock drifting it has been set into the future
(i.e. 1,5 hours ahead).
1) DoM self-signed certificate chain is created
with a validity time
stamp in the future. This could happen because either the system clock
on the machine which DoM runs on, or the media block secure clock is
out of sync. I don't know if there is anything we really can do about
this, apart from telling people that it is important to have accurate
clocks. Especially Dolby Cat745:s are notorious for drifting (usually
into the future though). The Cat745 clock in this particular case has
been verified as set accurately. Unfortunately I have so far been
unable to verify if system time on the system which DoM was run to
generate the content was set correctly.
The chain should only be created when DCP-o-matic is first run on a
machine, so unless the clock was way out I think this should only happen
if a DCP is made soon enough after DCP-o-matic's initial install.
Maybe it's possible to set the validity period of DoM's certificates to
start before "now" as a partial workaround? 2) uuid:s for
DoM:s KDM:s are reused. Why I suspect that maybe DoM
incorrectly re-uses KDM uuid:s is because the Cat745 log below
referencing an ID from the KDM XML issued with the same id after this
log entry
I don't think I follow this, sorry. The log is validating 4576cbc1...
where is the re-use?
10:02 p.m.
Maybe it's
possible to set the validity period of DoM's certificates to
start before "now" as a partial workaround?
Maybe a warning or a note in the manual is enough? Some media block's
secure clocks are prone to be really off. Especially the Dolby Cat.745
can be upt to 1,5 hours off in "normal" operation. The units I have
seen with the secure clock drifting it has been set into the future
(i.e. 1,5 hours ahead). I don't
think I follow this, sorry. The log is validating 4576cbc1...
where is the re-use?
Sorry, this was sort of a wild guess. I don't think this was ever the case. 
11 Jun
11 Jun
1:37 p.m.
Am 09.06.2018 um 22:48 schrieb Tobias Jingwall via DCPomatic:
Hi
When i'm trying to make a kdm key to my DCP clip i get this message
"Error - invalid/unauthorized clip signature"
Hi Tobias,
is the message coming from your DSS200 Server?
When, when ingesting the clip, or when trying to play it?
Do all your auditoriums use DSS200 and CAT745? All on the same software?
Is it an Interop or a SMPTE DCP/KDM
Where (geographically) are you located? This could actually be important...
- Carsten
2340
days inactive
2515
days old
7 comments
4 participants
participants (4)
-
Carl Hetherington -
Carsten Kurz -
Mattias Mattsson -
Tobias Jingwall