Documents signed with expired certificate are delayed to opening

[marcoscmonteiro]

Sometimes, when using PDF-XChange Editor Plus (8.0 build 336.0) to open old signed documents with expired digital certificate, I observed some delay to initiate the document viewing. Investigating the reason with Microsoft SysInternals ProcMon (https://docs.microsoft.com/en-us/sysint ... ds/procmon) I discover a strange behavior of Editor verifying all CRL endpoints of the expired certificate which sign the PDF document. Sometimes these downloads are very slow delaying the document initial show in some seconds because Editor freeze synchronously waiting to end all CRL downloads of all endpoints.

My first question is: If the certificate was expired why Editor are verifying CRL endpoints? For me it's not necessary...
My second question is: Why download all CRLs? If the first CRL is available, the others could be ignored and, in all my tests with Internet Browser, the first CRL is always available.

Note: When I open another document signed with NOT expired certificate, I don't observe this behavior: None of CRL endpoints are downloaded!

Is this a Bug? Can the Editor at least download CRLs asynchronously?

I attach 2 documents: One is signed with expired certificate and other signed with not expired certificate. I attached either 2 PML ProcMon captures (in .7z file) of PDF XChange Editor when open these two documents I attached. To observe what I mean you can filter ProcMon captures to show only operations beginning with "TCP".

Note: I observe the same behavior of the old and discontinued PDF-XChange Viewer when open these two documents. Perhaps this is a legacy bug of the old Software...

[TrackerSupp-Daniel]

Hi, marcoscmonteiro

I have asked our Dev team to take a look at this as well, but in the meantime, can you verify If you have enabled the option to "verify all signatures when the document is opened", and if disabling this option shows any improvement? Thisoption is found in the preferences (Ctrl+K) under Signatures:

PDFXEdit_HFkwR6YmSj.png

I ask because if this option is not enabled, the Editor should not do anything at all related to the signature during document opening.

Kind regards,

[marcoscmonteiro]

I tried the suggested hint but the checkbox was already blank.

[BigMike]

My first question is: If the certificate was expired why Editor are verifying CRL endpoints? For me it's not necessary...

It makes a difference if a valid certifcate was used to sign a document and the certificate expired after that or an already revoked certificate was used to sign a document and the certificate expired. So if the checkbox to verify the validity is checked, the CRL should always be checked to see if the certificate has been revoked at some time.

My second question is: Why download all CRLs? If the first CRL is available, the others could be ignored and, in all my tests with Internet Browser, the first CRL is always available.

I guess a CA provides the same CRL on all its distribution points (anything other would be strange), so getting one CRL should suffice.

Note: When I open another document signed with NOT expired certificate, I don't observe this behavior: None of CRL endpoints are downloaded!

I guess, this happens, because you have one of the checkboxes to verify the certificate validity unchecked. The first says "Check on open", the second "verify with CRL lookup".

[TrackerSupp-Daniel]

Hi, All

I have been testing further with these files and thus far been unable to notice any large delay when opening the "expired" document. Could you try creating a new Blank document with only a signature field, and placing each of your signatures in a separate copy, so that the content that needs to be loaded is the same, and confirm if you still see the delay or odd communication taking place?

Can you also please give use a rough estimate of how long the delay you are seeing is on your end? as I mentioned before, I see no really noticeable difference when opening the two here, the "not expired" document opens near instantly (fast enough that I couldn't time it if it tried), and the expired one, which is a document with additional content that may be the cause of any possible slowness in the first place, still opens in under a second (rough estimate at 0.6 of a second).

Also, BigMike certainly raised valid points, if both of the functions there are enabled, it would be expected to see behaviour has you have described, however if it is disabled, there should be no communication whatsoever during the opening process, unless the document itself has something internally prompting this.

Kind regards,

[marcoscmonteiro]

Hi, marcoscmonteiro

I have asked our Dev team to take a look at this as well, but in the meantime, can you verify If you have enabled the option to "verify all signatures when the document is opened", and if disabling this option shows any improvement? Thisoption is found in the preferences (Ctrl+K) under Signatures:
PDFXEdit_HFkwR6YmSj.png

I ask because if this option is not enabled, the Editor should not do anything at all related to the signature during document opening.

Kind regards,

I tested today and even if both showed checkbox are unchecked, the behavior are equal: PDF Editor remains download CRLs with respective delay to open digitally signed document with expired certificate but do not download CRL for signed document with NOT expired certificate.

Do you know how much time to dev team evaluation of this problem?

[marcoscmonteiro]

Hi, All

I have been testing further with these files and thus far been unable to notice any large delay when opening the "expired" document. Could you try creating a new Blank document with only a signature field, and placing each of your signatures in a separate copy, so that the content that needs to be loaded is the same, and confirm if you still see the delay or odd communication taking place?

Can you also please give use a rough estimate of how long the delay you are seeing is on your end? as I mentioned before, I see no really noticeable difference when opening the two here, the "not expired" document opens near instantly (fast enough that I couldn't time it if it tried), and the expired one, which is a document with additional content that may be the cause of any possible slowness in the first place, still opens in under a second (rough estimate at 0.6 of a second).

Also, BigMike certainly raised valid points, if both of the functions there are enabled, it would be expected to see behaviour has you have described, however if it is disabled, there should be no communication whatsoever during the opening process, unless the document itself has something internally prompting this.

Kind regards,

I tested with both functions disabled and analyzing the behavior with Procmon, CRLs continue to be downloaded only when open signed document with expired certificate.

The delay is intermittent: sometimes download time of CRLs are almost instantly, sometimes not. This delay depends if certificate issuer site are overloaded or not. In worst case I took 18 seconds to open the signed document with expired certificate.

I cannot sign the document with expired certificate because it's not mine and I do not have a expired certificate to emulate this scenario.

Thanks

[TrackerSupp-Daniel]

Hi, marcoscmonteiro

No worries, I will continue with my tests here as well, and If I can find a workaround for you I will let you know but for the time being, the best I can offer is that you wait until the Dev team is able to address this issue in a future build.
They are still undergoing their investigation and we now have a formal ticket on the issue, it seems that the error in this case is most likely an error forcing the Editor to initiate the verify signature operation on expired signatures, despite other settings. As for downloading all CRLs, this is actually dictated by Windows during the signature verification process, we do not have control over which are downloaded, when, or why, and simply follow the instructions provided by windows for checking these.

For reference the Ticket number is as follows:
RT#5136: Editor tries to verify expired signatures always
While I cannot provide a timeline for this, know that they are looking into it currently, and we will do our best to have this resolved as soon as possible.

Kind regards,

[marcoscmonteiro]

Any news for:

For reference the Ticket number is as follows:
RT#5136: Editor tries to verify expired signatures always

?

[TrackerSupp-Daniel]

Hi, marcoscmonteiro

The ticket has been assigned a work item, but does not appear to be resolved for the upcoming 338.0 release.

Kind regards,