Identrust Unlock Code

[Nella Mcnairy]

The EV Code Signing certificate private keys are stored in IdenTrust supplied FIPS 140-2 Level 2 or higher hardware compliant crypto-modules such as HID Global USB tokens or HID Global Smart cards. IdenTrust also supplies the SafeNet eToken 5110 CC (Common Criteria) as compliant USB token. The additional security features in these harware devices enable two-factor authentication and prohibits the private key from being exported, thus offering additional assurance to relying parties with respect to the ownership of the certificate.

Use of CSR (Certificate Signed Request) is supported during the EV Code Signing certificate application; once approved, the certificate can be installed in the applicant's hardware security module (HSM) meeting standard security equivalent to FIPS 140-2 level 2 or Common Criteria EAL 4+. Enforcement of this requirement is handled via the Subscriber Agreement.

As a value-added service to an EV Code Signing certificate, the IdenTrust Timestamping Authority Server (TSA) is offered free of charge and provides RFC 3161 compliant timestamping services. Timestamping binds the EV Code Signing digital signature, the signed code and an accurate date and time. Upon execution, timestamped files are automatically validated for integrity, alerting the user if the file is no longer in the same state as when it was timestamped. Timestamping adds long term integrity and non-repudiation validation for up to 10 years after the EV Code Signing certificate has expired or has been revoked.

Use the IdenTrust Timestamping Authority Server (TSA) which is offered free of charge and provides RFC 3161 compliant timestamping services to bind the EV Code Signing digital signature, the signed code and an accurate date and time.

I see that another company reported the same problem back in Feb 2022 and the indication was that IdenTrust's TrustID CA 4 certificate is not valid and thus code files signed with this certificate will not be recognized as EV certificate recognized by Microsoft. Crypt32 (a MSFT MVP) says that "it seems the problem is with the issuer of your EV signing certificate (not with your signature or tool)":

IdenTrust is still selling EV certificates, apparently without these being trusted by Microsoft which seems super sketchy, and potentially fraudulent (especially for a company whose whole purpose is trust).

I've addressed this with IdenTrust customer support and they've acknowledged that Microsoft does not recognize their code signing certificate authority and that they have no idea if or when this might happen.Even after stating this, they refusing to issue a refund due to a "strict refund policy".

To summarize: an EV Code Signing Certificate purchased from IdenTrust today or perhaps from several months ago is probably no better on Microsoft platforms than a self-signed certificate I could create myself for free.

Given that IdenTrust appears to be currently selling code signing certificates that are not actually trusted by Microsoft, I recommend that Microsoft remove these references to IdenTrust from their website and open an investigation into this behavior, if an investigation isn't already in progress.

ActivClient is signed by an IdenTrust code signing certificate which may not be pre-installed on all Windows workstations. If your environment automatically receives the latest root certificates from Microsoft (most common scenario), then the IdenTrust code signing certificate will be trusted.

In other cases (workstation not connected to the Internet, ActivClient installed by push mechanism), administrators need to install the IdenTrust root certificate on the workstation prior to installing ActivClient. To download the latest root certificates from Microsoft, click here.

o If Microsoft does not provide the latest root certificates for your environment (Windows version no longer supported by Microsoft), you may also retrieve the root certificates directly from IdenTrust, click here.

IdenTrust, part of HID Global and headquartered in Salt Lake City, Utah, is a public key certificate authority that provides digital certificates to financial institutions, healthcare providers, government agencies and enterprises.[1] As a certificate authority (CA), IdenTrust provides public key infrastructure (PKI) and validation for digital certificates, including TLS/SSL certificates, email security via S/MIME certificates, digital signature certificates, code signing certificates and x.509 certificates for protecting network and IoT devices.

Announced in 1999, its founding members included ABN AMRO, Barclays, Chase Manhattan, Citibank, Bank of America, Bankers Trust, Deutsche Bank, and HypoVereinsbank.[2] Early on it opted for a technology-neutral policy, developing standards that multiple technology vendors could follow in implementing products and services for its members and customers.

Initially located in New York, NY, it is presently headquartered in Salt Lake City, UT.[3] In 2002 it acquired Digital Signature Trust (DST) for an undisclosed amount,[4][5] which had previously acquired the American Bankers Association's ABAEcom project.[citation needed]

IdenTrust was acquired by HID Global in 2014.[6][7] They cross-signed the intermediate certificates of Let's Encrypt in 2015, so that Let's Encrypt CA could begin operations and be trusted in all major browsers as well.[8]

Providers who wish to electronically prescribe controlled medications must employ two-factor authentication as required by the DEA. Medical Informatics Engineering (MIE) works with IdenTrust to provide the required level of identity proofing needed for Electronic Prescribing for Controlled Substances (EPCS). IdenTrust will issue digital certificate tokens that can be used to digitally sign and electronically transmit prescriptions for controlled substances. By providing required information to IdenTrust, providers can complete identity proofing and establish two-factor authentication for two years. Providers will receive a USB device that will generate a digital signature.

THE APPLICATION AND IDENTITY VERIFICATION PROCESS MUST BE COMPLETED AND SUBMITTED BY THE REGISTRANT AND SUBSCRIBER OF THE CERTIFICATE. THIS CANNOT BE COMPLETED BY PROXY, OR BY ANY OTHER INDIVIDUAL ON BEHALF OF THE PRESCRIBER. FAILURE TO COMPLY COULD RESULT IN REVOCATION OR SUSPENSION OF THE DIGITAL CERTIFICATE.

When prescribers are ready to purchase the certificate and/or token, there is a simple 3-step process provided through IdenTrust. Simply fill out the application, verify your information, and receive your certificate and generate its key for use.

There is a recording walking to watch someone walk through all the steps (the video has no sound). If you start at about 3:30 on the normal speed video in this folder: -0HGtSKwTYpz8oZmQMELkRs9SZEaQzqG?usp=sharing

Congratulations! You have just completed the first phase. Thank you for applying for your IGC Basic Assurance Hardware Unaffiliated Certificate 2 Year. You have completed the application phase, so now IdenTrust will initiate the approval of your application.

This portion of the second phase (carried out by IdenTrust) consists of validating the information you provided against independent data sources. You will not need to do anything during this stage; you will receive a retrieval kit from IdenTrust in the mail if your application is approved. You will be able to check on the Application Status under Your Account Information:

You have entered the third and final phase, which consists of obtaining your digital certificate and generating your keys for use of certificate. This phase begins once you have received your retrieval kit in the mail. Included in your kit will be a letter explaining how to do the following:

This is the Token Passcode for your USB Token which must not be forgotten. If you forget this passcode your certificate will be permanently locked and cannot be recovered.

Do not press the Back button on your browser at any time. Pressing Back during the retrieval may cause the retrieval system to void your retrieval, closing your application and forcing you to apply again from the beginning.

We recently upgraded to Acrobat DC. We have documents that have been digitally signed. Now when someone else opens them it says "The validity of the document certification is UNKNOWN. The author could not be verified." I've read up as much as I could (didn't know anything about them except how to sign a doc with one) and I've checked several things and can't find the problem. When I go to the certificate viewer it shows that we have a Certificate Authority. I read on another post that the latest Acrobat/Reader version enforce "Extended Key Usage" (EKU) attribute in the signing certificate. I checked that out and the OID (not sure what that stands for) that permit signing has five things: server authentication, client authentication, code signing, email protection and TimeStamping. It says in the Revoation tab "The selected certificate does not chain up to a certificate designated as a trusted anchor (see the Trust Tab for details). The result is that revocation checks were not performed on this certificate." It seems that I could "Add to Trusted Certificates" but we've never had to do that before, why now? Not to mention it advises me that I shouldn't do that. Please help. Thanks! Let me know if you need anything other information to trouble shoot.

Make sure that you trust the root of the certificate chain (only if you really-really trust it!). Right-click on the signature (either the signature field or in the Signature Panel on the left), select "Show Signature Properties.." in the drop-down list and then "Show Signer's Certificate". You'll see the trust chain in the left-hand panel of the "Certificate Viewer" dialog (if the signing certificate is self-signed it will be the only one in the chain). Select certificate in the chain that you trust (if you trust any) and click the "Trust" button on top of teh right-hand part. Then select the trust level and click "Add to Trusted Identities" button. Be extra careful to trust self-signed signing certificates.

c80f0f1006