You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Digital Signature Error "The Certificate could not be trusted 1416"

Laserfiche Version 11
Updated February 25, 2022
posted on January 24, 2022

Hello, 

We have a customer who tried the following and received the below error:

I recently tried the digital signature on a desktop and got an error message that said, “the certificate could not be trusted.”  Could this have something to do with the fact that when I got the certificate originally I was remoting to a specific machine, whereas now I am remoting into a virtual desktop.

Do Digital Signatures work with Virtual Desktops?

Appreciate the feedback,

Jeff Curtis

0 0
replied on January 24, 2022

Hi Jeff,

How did you issue the certificate in the first place? If it was self-signed, the only place it would be trusted is on the server that issued it. 

Certs for digital signatures should be issued by either an Active Directory (or other internal) certificate authority or a 3rd party trusted one. The virtual desktop (or any client) environment needs to trust the issuing root certificate authority, which I'm guessing isn't happening here.

Cheers,
Sam

1 0
View 5 previous replies
replied on January 25, 2022

Hello Sam,

Thanks for the information.

I am checking with the customer confirm certificate process.

Jeff

0 0
replied on February 8, 2022

Hey Sam,

Below is the listed Issuer for this certificate. I have never heard of this before...is this a possible self-signed cert??

Thanks,

Jeff

 

0 0
replied on February 8, 2022

Hi Jeff,

Yes, that appears to be self-signed as the Subject matches the Issuer. You can confirm this by selecting the "Certification Path" tab next to "Details" in the certificate properties window. A self-signed certificate will have only one entry in the certification path - itself.

A certificate issued by a Certificate Authority will show the root certificate, any intermediate certificates, and then the final "leaf" certificate in a tree structure. For example, here is the certificate for Answers:

In any event, that certificate does not look like it's intended for use for digital signatures. "FailbackAgentSpnCert" sounds like something some other program generated for its own use.

1 0
replied on February 9, 2022

Thanks Sam!!

Have let the customer know.

Jeff

1 0
replied on February 18, 2022

Hello Sam,

Customer let me know that they have Digital Signature installed on other workstations that self-signed certs only and it works.

Is this not suppose to be the case?

Thanks,

Jeff 

0 0
replied on February 21, 2022 • Show version history

The customer's statement raises a few concerns.

To start, the entire point of digital signatures is to provide cryptographic identity verification for the signer plus a tamper detection mechanism. The identity verification component requires both that the certificate(s) be issued to a specific user as the Subject and by a trusted certificate authority that (hopefully) validated the user's identity before issuing them a cert with their name.

Here's an example of my own document signing certificate issued by one of Laserfiche's internal corporate certificate authorities:

Not having either of these elements in the signing certificates is like having people going around signing documents as fictional characters (or literally anyone) and then writing "Notarized" in crayon on them.

Using self-signed certs means I can sign documents with this one I just created:

or this:

No one should accept either of those.

You'd honestly be just as well off using text stamp annotations because at that point you're relying on Audit Trail logs to verify the user identity for the signatures.

Seeing a document signed with a self-signed certificate with a subject of "FailbackAgentSpnCert" issued by itself tells me nothing reliable whatsoever about the signer. 

DocuSign has a nice bit about the importance of Certificate Authorities for eSignature here: https://www.docusign.com/esignature/electronic-signature-certification and publishes information on all their public certificate chains here: https://www.docusign.com/trust/compliance/public-certificates

To conclude, the only reason self-signed certs would be working for this customer on other workstations is if they took actions to explicitly trust those certificates on said workstations. I noticed the "FailbackAgentSpnCert" certificate was issued Jan 12, 2022, and it was probably never added as a trusted root certificate on that workstation.

Regardless, using self-signed certs for digital signature is a Bad Idea unless you truly do not care at all about validating who the signers are, in which case why are you using digital signatures in the first place?

1 0
replied on February 24, 2022

Thanks Sam!!!

If a customer has a WC SSL Certificate currently, can they install that on any machine they want to use the Digital Signature? 

I just want to confirm if the WC cert is used for Auth to server via HTTPS, would a separate Cert be needed to keep these segregated?

Jeff

0 0
replied on February 25, 2022

As Sam was saying, a lot of the value of a cryptographic digital signature comes from the identity of who the signing certificate was issued to. If your organization has arranged it so that only Sam has access to the certificate issued in his name, your users can be confident that it was actually he who signed the document. What does it mean to your users if they see that the web server has signed a document? It doesn't really have value.

And on the flip side, what does it mean if entities other than your web server have access to a certificate issued to the web server? It means that they can present themselves as the web server. It would be technically possible for them to host a phishing site whose https certificate declares that the site is yours.

Digital signatures leverage your PKI - there's not much value in trying to adopt signatures without PKI.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...