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.
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.
I have an application that receives items from a high-speed scanner device. As the items are received, they are written to disk using SQL Compact. The following digitally signed Microsoft DLLs are used:
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
I recieved a performance complain from a customer, and traced the issue using Microsoft Procmon to a TCP Reconnect failure when attempting to contact the site for certificate validation when we make calls to methods in these dlls. At first, I could not recreate the issue locally. After talking to their infrastructure people and developers, I learned that they must use a proxy for internet connectivity. Some of the customer's users (in the test environment) had valid proxy settings, and they got good performance from our application. Naturally when they turned their proxy settings off, the validation could not be done and the performance issue arose.
I attempted to recreate the issue by setting our machine up with false proxy settings to a non-existent machine. On my initial attempt, I still got good performacne from our application, and no attempt was made to contact the internet for cert validation. After looking at the cert's validation chain, I noticed that it derived from the certificate "Microsoft Root Certificate Authority". I then exported and deleted that Cert, and was able to reproduce the issue as determined by a comparison of logs.
I did the following tests:
Test 1:
1. Opened the proxy settings, and enabled them pointing to a non-existent address.
2. Ran a test.
Results: No performance issue.
Test 2:
1. Exported the “Microsoft Root Certificate Authority” cert and moved it to the untrusted folder.
2. Ran a test.
Results: The performance issue occurred.
Test 3:
1. Deleted the “Microsoft Root Certificate Authority” cert.
2. Started a test.
Results: The performance issue began occuring.
3. While the test was in progress and device was hesitating I removed the false proxy settings.
Results: The performance issue disappeared and the application recovered.
Tentative Conclusions:
1. That I can simulate the no internet access condition by providing false proxy settings.
2. If the “Microsoft Root Certificate Authority” cert is installed properly, the .Net infrastructure does not need to access the network to verify the necessary cert.
3. If not, it will attempt to validate via the internet connection.
Nevertheless, when the customer checked the certificates in the "Trusted Roots Certificates" folder of mmc->certificates-local computer. The "Microsoft Root Certificate Authority" certificate does appear there, and it seems to be identical to mine. Yet for some reason the use of the dll's causes certificate validation to attempt to access the internet resulting in a performance issue.
In the customer's situation, eventually devices will be used in production with no internet access.
My question is, is there a setting (registry, or GPO) that might cause certificate validation to always attempt to use the internet, regardless of whether the root certificate of the validation chain is installed in the local computer?
Can a setting be enabled that causes a certificate validation to access the internet to check to see if the root certificate has been revoked, for example?
Please feel free to ask questions if you need more information.
This appears to occur for SQL Server Compact 4.0 on any system with an invalid proxy configuration, as a Certificate Revocation List check is run each time the engine is loaded (which happens on the first call to .Open()).
Solution: To avoid this delay, which probably affects any signed app on the system in question, you must fix the configuration or disable the check. The check can be disabled via UI or via registry settings, as described here: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282
For additionla issues see my blog post here: http://erikej.blogspot.com/2013/08/faq-why-is-opening-my-sql-server.html
I've noticed that this question has been asked several times but none of the results provide a solution to my problem.
I am developing a website for a client. The website is http://www.entirelyintimate.com.
It is a dropshipping website that uses Paypal Pro for their checkout process.
We purchased and installed the SSL from Godaddy.
According to an SSL checker website, the chain and installation appears to be correct.
I removed all insecure content on the pages that need to be secured
1 example - https://www.entirelyintimate.com/checkout-complete
I checked the page on - whynopadlock.com and it appears to be good there.
But... I still receive the dreaded Error code: sec_error_revoked_certificate
I am pretty new to SSL so I could be overlooking something basic. Any help would be appreciated.
p.s. This community is really great. I come lurking here all of the time when I have questions. I do an automatic click when I see this website in the Google search results.
sec_error_revoked_certificate means that the certificate has been revoked.
Your certificate may be issued by a CA trusted by your browser and valid in time, but the CA may have revoked it, and your client is checking for revocation (which is recommended).
Certificate revocation is a mechanism that makes it possible to invalidate a certificate before its normal expiry time. Checking for revocation can be done via CRL or OCSP by the clients.
Typically, certificates are revoked upon request from the entity corresponding to that cert (i.e. the user or the server admin) if the private key has been compromised, if the CA decides the validating data wasn't sufficient after all, or perhaps automatically if the CA issues another certificate to the same entity.
A possible cause for the problem could be that you might have re-keyed your certificate, thereby making your CA revoke the old one. If you're still using the old one inadvertently (perhaps it's still available to your server in its keystore or equivalent) this error could happen.
Qualys SSL Labs's SSL checker is generally a more complete tool for checking your SSL/TLS configuration. It seems to indicate that your certificate has indeed been revoked.
The error cause is exactly as stated: the security certificate has been revoked.
You can verify it here by entering the checkout page address.
I am afraid you will need to check this with GoDaddy.
0x4F0DB30A63474B: revoked
This Update: Sep 11 17:52:23 2012 GMT
Next Update: Sep 11 23:52:23 2012 GMT
Reason: cessationOfOperation
Revocation Time: Sep 10 01:39:38 2012 GMT
As part of a ClickOnce deployment I'm running mage.exe
mage.exe -Sign "manifest file" -CertFile Cert.pfx -Password yepit5right -TimeStampUri http://timestamp.verisign.com/scripts/timstamp.dll
the certificate comes from Verisign in the first place so using their timestamping service.
This works fine on some machines but not others, and they come back with the very readable error code of -2147012865 which translates to error 12031 - ERROR_INTERNET_CONNECTION_RESET.
I can connect out through IE on that machine to sites such as stackoverflow.com and so the proxy settings which it needs appear to be correct.
Does mage.exe support authenticating proxies? This used to work, over a year ago now, before we had a major outbound proxy change which I think included changing from non-authenticating to using integrated authentication at the proxy layer.
Thanks
Not a great answer but it turns out that mage.exe cannot authenticate through to a proxy when making the request out to the timestamping service.
To get around this restriction I have added the source machine and the target URL to our outbound proxy's "whitelist" of requests that are allowed out without requiring proxy authentication. As you could imaging doing this within a corporate environment where the security team own that list was not a simple task, I much prefer cracking the technical nut.
As soon as this was added mage.exe started behaving as expected, and as it behaves in our test environments which have a non-authenticating proxy.
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