My Ev-code signing license is expiring, and i'm thinking about changing provider. However the new provider(Trust zone) is providing a safenet etoken 5100, the one i have now is a safenet etoken 5110. My questions are these:
What are the differences, if any?
Does the safenet authentication client support the safenet etoken 5100?
I tried finding information about the differences online, and in the safenet documentation, but without any luck
Related
Recently our SafeNet Authentication Token used for software and driver signing expired (Symantec) and we ordered a new one (now Thales, bought Symantec?).
The expired one had these CAs:
VeriSign Class 3 Public Primarey Certification Authority - G5
Symantec Class 3 Extended Validation Code Signing CA - G2
The user certificate has the intended Purpose: Code Signing
The replacement token has these CAs:
Digicert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Digicert Trusted Root G4
The user certificate has the intended Purpose: Code Signing
With the old token:
We could sign driver and catalogs and use these direct on
PCs without Secure Boot. We could attestation sign these drivers at Microsoft
to get them to work on PCs with Secure boot.
With the new token:
We can sign drivers and catalogs. We can attestation sign these drivers at Microsoft to get them to work on PCs with (and without) Secure boot.
But they no longer work on PCs without Secure Boot.
The device manager presents this:
Windows cannot verify the digital signature for the drivers required
for this device. A recent hardware or software change might have installed
a file that is signed incorrectly or damaged, or that might be malicious
software from an unknown source. (Code 52)
The driver itself presents the new signature:
And a nice chain of trust:
One possibility to get this still working on the test PCs,
would be to disable driver verification using "bcedit".
But I would not like to force beta testers to do it. Also, I do
not want to manually "attestation sign" every CI build...
This wrecks out CI infrastructure and automatic test environment.
My questions:
Is this intended behavior with new code signing tokens?
Did we receive a bad or not-good-enough token as a replacement?
This is the command-line of signtool:
sign /s MY /sha1 KEY_SHA1 /n "My GmbH" /fd sha256 /tr http://timestamp.digicert.com' driver.sys
I ask this openly because I think there are a few guys in different companies
getting these issues with token updates and I hope the answers to this thread will help them (and us).
Bye Gunther
Ok today I found out:
Microsoft deprecated code signing certificates mid 2021:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates#will-we-continue-to-be-able-to-sign-non-driver-code-with-our-existing-3rd-party-issued-certificates-after-2021
Very short answer: New certificates like our new code signing dongle are not cross-signed to "Microsoft Code verification Root" or do not provide any cross certificate chain.
So our signed driver will not load in production Windows.
Possible Options for testing and debugging:
Enable testsigning:
bcdedit /set TESTSIGNING ON
In this mode any driver with or without signature is allowed.
If I understand correctly, aws + graphql for mobile app is quite similar to Firebase Realtime Database. As the
firebase blog certificate pinning is supported behind the scenes. My question is: does graphql support certificate pinning?
Certificate Pining allows to bypass standard certificate authority chains to mitigate the risk of an valid certificate be issued to a criminal. It is now deprected. What Firebase has implemented and what you probably mean is Certificate Transparency (CT).
https://www.certificate-transparency.org/
Google's Certificate Transparency project fixes several structural flaws in the SSL certificate system, which is the main cryptographic system that underlies all HTTPS connections. These flaws weaken the reliability and effectiveness of encrypted Internet connections and can compromise critical TLS/SSL mechanisms, including domain validation, end-to-end encryption, and the chains of trust set up by certificate authorities.
Beginning April 24, 2018, AWS Certificate Manager (ACM) supports Certificate Transparency. See the following blog post for more details:
Preparing for AWS Certificate Manager (ACM) Support of Certificate Transparency
Certificate pinning is browser's feature.
And yes, almost browsers (Chrome, Firefox, ...) support Certificate pinning.
We sign our executables on the build server. Suddenly the build server failed to build giving the error:
SingTool Error: The sepcified timestamp server either could not be reached or returned an invalid response.
After changing the timestamp server to http://sha256timestamp.ws.symantec.com/sha256/timestamp, singing did work again.
Are there any issues with our old url? Why is it not available anymore?
Could we have some (security) issues with the old signed files or the new url?
I know this is a little bit broad I just don't want to miss anything...
I asked Symantec about that, so they sent me this link: https://knowledge.symantec.com/support/partner/index?page=content&id=NEWS10071&viewlocale=en_US
By April 18, 2017, Symantec will decommission the "Legacy"
timestamping service.
(Legacy) RFC 3161 SHA128 Timestamp Service:
https://timestamp.geotrust.com/tsa
To support business continuity for our customers, we have provided the
following replacement services.
(New) RFC 3161 Service SHA256:
http://sha256timestamp.ws.symantec.com/sha256/timestamp
Important: Customers must leverage SHA256 Timestamping service going
forward, and should not use a SHA1 service unless there is a legacy
platform constraint which doesn't allow use of SHA2 service (in this
case you can use this new URL: RFC 3161 Service SHA128:
http://sha1timestamp.ws.symantec.com/sha1/timestamp).
Background and Key Industry Mandates affecting the Timestamping
services
To comply with Minimum Requirements for Code Signing (CSMRs) published
by CA Security Council and Microsoft Trusted Root Program Requirements
(section 3.14), Symantec has set up the "new" RFC 3161 (SHA1 and SHA2)
service as per specifications and requirements laid out by section
16.1 which requires FIPS 140-2 Level 3 key protection. In the near future, Oracle will be taking steps to remove SHA1 support for both
Java signing and timestamping. This will not impact Java applications
that were previously signed or timestamped with SHA1 as these will
continue to function properly. However, Java applications signed or
timestamped with SHA1 after Oracle's announced date may not be
trusted.
Working link for timestamp from another provider:
http://tsa.starfieldtech.com
You can also try:
http://timestamp.globalsign.com/scripts/timstamp.dll
http://timestamp.comodoca.com/rfc3161
You can choose KeyStore Explorer (sign tool with good GUI). It has default and not be working link http://timestamp.geotrust.com/tsa
If so, do not forget to change the unworking link in the option TSA URL (Add timestamp) with other working options.
For example, this option (link) worked for me fine:
http://tsa.starfieldtech.com
I experienced the same TSA issue starting on 2017-04-21. Switching from https://timestamp.geotrust.com/tsa to http://sha256timestamp.ws.symantec.com/sha256/timestamp fixed our problem as well, so thanks for the pointer. The specific error I received using the old URL was that jarsigner returned"java.net.socketException: software caused connection abort: recv failed."
The Verisign knowledge base article AR185, updated 2017-03-16, recommends the jarsigner arguments "-tsa http://sha256timestamp.ws.symantec.com/sha256/timestamp" where it used to recommend https://timestamp.geotrust.com/tsa . This documentation change suggests to me that the disabling of the URL may be intentional, but I don't know whether that has any implications for the level of trust of JARs signed using the old timestamp server.
Good afternoon everyone!
As you may know, many companies that sell SSL certificates offer free trial certificates (that usually expire in 30 or 50 days). StartCom is the exception - they give 1-year free SSL Class 1 certificates.
The question is: are these certificates enough for me to sign my Firefox extension? Note: I'm not asking if these are good for the task - I want to discuss only the physical possibility of code signing the xpi file with these free certificates.
Thank you.
You need a code signing certificate and not an SSL certificate to sign an add-on. None of the ones you listed will work.
I have not heard of the "trials" you are talking about, but if they are legitimate certificates then they will work. I would recommend reading the Certificate Authority and the Public key infrastructure articles on Wikipedia.
You can sign anything with any certificate provided you have the private key.
Whether the certificate is valid is another issue.
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other