My company purchased an EV Certificate from Symantec to use for a software product we produce. Specifically it is called: Symantec Class 3 Extended Validation Code Signing CA – G2.
We apply the Certificate to the execuatables and DLLs using signtool.exe, and this has accomplished our main goal of eliminating the SmartScreen warning during installation on Windows 8/8.1.
However, the install dialogs produced by our ClickOnce installer are showing:
Publisher: Unknown Publisher
We have tried everything we can think of to solve this including contacting Symantec Tech Support. They have not been able to help us, and could only advise us to call Microsoft for help. We thought asking here would take us further.
Has anyone else run across this problem? Might anyone know of a solution?
When using signtool try to use /d and /du options. I was having similar problems with activex installations and this helped me.
For more information please look at this page.
Related
I hope someone could give some tips to fix this potential SSL issue.
I am using Oracle JMC5.5.2 bundled with Oracle JDK8u231 and getting this exception when:
going to Help > Check for updates or
Help > Install New Software ...
As a result, this client based on Eclipse is unable to contact the server.
Is there any way to troubleshoot this issue? it seems the certificate sent by the server is expired.
Available Software Sites has no reference to https:
Also, I tried the same with Oracle JMC8, which has a completely different graphic interface, but that issue isn't replicated.
Now based on Enable Java to permit expired certificate
if the expired cert is added to the trusted key store file, that validation will pass. The thing is JMC is based on Eclipse, and the configuration files are under <JAVA_HOME>\lib\missioncontrol\configuration folder. If the javax.net.debug=ssl option is added to the config.ini file, where can I get the corresponding output?
Is there any way to tell this JMC(based on Eclipse) to write the stdout to a log file, thus I could know what cert is received and which cacerts is used?
Thank you very much!!
UPDATE:
I am not going to insist on the old JMC5.5.2 anymore, and just moved to JMC8 (where that issue isn't seen). I've spent last week studying the new interface, and it's awesome. The line of development of JMC6 is completely different. It was redone from the scratch, not only affecting its core, but the UI as well. It’s a completely brand new concept.
It introduced a sophisticated automated analysis report, a different layout, lots of filters, and the performance was improved dramatically.
I switched to JMC8. It has the same and much more.
I came across very little literature to use code signing certificates without a private key being exported. Hence, requesting some basic info regarding including the code signing certificate in the installshield 2013 to sign our setup.exe file.
So it goes like this...
We had a certificate from Symantec and/or Verisign that expired a few days ago. So we got a new certificate from them which is a SHA-256 cert. However, they won't release the private key. Hence we cannot generate a .pfx file which used to include in our installshield. They say that, here on who ever wants to do the code signing using installshield needs the dongle attached to the computer to get the private key verification done. I don't quite understand what they mean. However, it is clear that they want us to connect with the dongle for private key verification. So if I do not have the pfx file, how can I achieve code signing using installshield 2013? I also read on the Web that the support for SHA-256 certs was not available in 2013 and that one would have to migrate to 2015 or above to do something of that sort. So we have hit a roadblock with this thing and our automated build process is failing.
Hence, request you to provide me any pointers as to how can we get this thing done.
Thanks and Regards,
Bhushan.
InstallShield 2015 or so added support for signing using certificates from certificate stores. Before that, some people have intercepted the call to signtool, implementing their own calls to either the real signtool or the APIs it calls. This should give you the freedom to use your dongle-based private key, or anything else you need.
(On the downside, InstallShield 2015's and later implementation doesn't let you do this interception trick.)
Ok...So it goes like this...We have a rights issue. As per Symantec, only the person who is the owner of the certificate, can generate a private key on his machine with his admin privileges and that too using IE 11 browser. Now the issue is, the certificate request goes to a helpdesk portal, pending an approval and then forwarded to symantec after the necessary approval. Looks like the approver has to act as the owner, even though the requesting team has paid for the certificate. That is weird but true. So the person who receives all the certificates first hand has to download the certificate, export the certificate along with the private key into the .pfx file and then send us the .pfx! Meanwhile, is there any possibility that I run the export certificate wizard from the browser and the export .pfx option is disabled just because the user launched the browser with insufficient privileges? How may I confirm that this is a rights issue? Thanks.
Further to these, I simply have a very general question about signing. The thing is, even though I know what code signing is and some of the applications might absolutely need it, I do not see a substantial need for the windows based desktop applications. I may be wrong on this. However, all the literature I see points to the fact that the authority that is publishing should be trusted. Now we as a team are responsible for a suite of desktop applications that are being packaged using installshield and code signed by Symantec SHA 256 class certificates. We only sign the set.exe file and as a result it shows a typical trust prompt to the user who installs our software. Our users are a rather closely knit group of clients and are easily approachable. Also, I do not see a risk of our network being intercepted and hacked to tamper the content of setup. In such a situation, is having a certificate justified?
I have a few questions with respect to SignTool as well. I understand that the signing for our certificate is currently failing because we have not yet procured the private key for it. However, the timestamp verification is also failing for a self signed certificate that I have generated for testing purposes. So I need to understand what exactly is a timestamp doing in installshield when Signtool is invoked? Installshield is a good product; however the supporting documentation provided by Flexera is rather pathetic. Thanks.
One of my projects requires that a COM server be registered on the build machine. My first (and only) lame attempt was a simple pre-build step, but I assumed that would not work in the cloud, and I was correct. Problem is, I need to use this component, I only have a binary, and I'm a bit stumped as to what to do.
The error message is predictable:
The command "regsvr32 /s "path_to_dll" exited with code 5. Please verify that you have sufficient rights to run this command.
TFS Azure is in preview at the moment, so I'm not sure how many people have experience with it yet. I posted the same question on the official forums and have not yet received a response. Searching did not help either.
Silly me, just need to reference the interop assembly instead of directly referencing the native DLL. Problem solved.
I work for a company that sells USB devices and provides drivers for them.
In Windows 7, you could install and use unsigned INF driver files for USB devices as long as they didn't add any code to the kernel. Our company uses generic drivers provided by Microsoft (usbser.sys and winusb.sys), so we never needed to sign our driver packages.
Based on a report from one of our customers and from another Stack Overflow question What changed in the driver signature requirements for Windows 8? and the Arduino forum, it sounds like the Windows 8 Consumer Preview has stricter signing requirements that require all third-party INF files to get signed. The error message people are getting when trying to install drivers that worked on Windows 7 is:
The third-party INF does not contain digital signature information.
What is the official word from Microsoft that confirms that the signatures will still be required in the final version of Windows 8? A sentence or two from MSDN.com would be sufficient, but I can't find anything.
I am considering buying a signing certificate, but before I pay $200 I want to be sure I will actually need it in the long term. It's possible that the new signing requirement is just in the consumer preview and not in the real version?
To answer my own question: Yes, the final version of Windows 8 does require all INF files to be signed, but you do not need to submit your drivers to the WHQL. I wrote about this requirement and much more in my article Practical Windows Code and Driver Signing.
Not only does it require signing of INF files, it also requires them to be signed by the WHQL certificate, not the same one that you use to embedded-sign .sys files and the like. Using my Code Signing certificate on the INF file didn't work at all. (Same problems as if left unsigned.)
EDIT:
This is what Microsoft wants you to think. They said that certain classes of drivers HAVE to be WHQL signed, otherwise they won't work, and that Authenticode signing works only for those who don't have a WHQL process.
It turns out you CAN Authenticode sign driver packages, except you have to take care and sign them like you would kernel code now, which means getting the correct cross certificate for your CA (from Cross-Certificates for Kernel Mode Code Signing, there are tons of them now, including StartCom, which I have (class 2, US$60 for two years, but they can't be timestamped). Supply this cross certificate (not the same as your CA's self-signed certificate, or their intermediary certificate. It's only available on that MSDN page) to SignTool via the /ac switch.
Then use SignTool verify with the /kp switch to see if you cross signed them properly. SignTool verification with without any switches REQUIRES that the .cat files are WHQL signed, while the /pa switch, which seemed to be OK before, is now too lax, and only applies to non-driver signing (like EXE files, ClickOnce, etc.).
If you don't want to acquire your own kernel-level signing certificate (which is easier now than before, frankly, before it was limited to VeriSign's super expensive, and GlobalSign US$200-a-year ones, I guess Microsoft saw that not many people wrote kernel-level exploits for x64 systems), you can make a self-signed root CA, have your driver installer install it into the LocalMachine's "Trusted Root Certification Authority" store (see certmgr.exe), and then install the .cat file which was signed by that. Of course, since this isn't a kernel-level code certificate, you MUST use only .sys files which already have an embedded kernel-level code certificate from someone else (which means, you can only modify .inf files in driver packages). Apparently, there's some loophole that allows self-signed certificates to sign .cat files (if you made your own CA, then signed a certificate with it, then signed your .cat files with that, it won't work like this).
For a suite that does this for every driver INF package it makes, see libwdi, and how their self-signed certificates on cat files allow installation on Windows 8.
EDIT2:
Removed CERTUM "open source" developer certificate mention, as it's not cross-certified by Microsoft (The one you get isn't the Certum TRUSTED NETWORK one, that Microsoft cross-certified).
I am supposed to fulfill a common-for-most-developers request to build/consume secure services using ssl/tls... via various communication protocols, not necessary wcf (web) services.
My problem is that I don't know much about certificates and I have been trying to get my background knowledge up to speed on the entire process.
The organization I am coordinating with issued 3 files for me to use:
AppName.cert.pem
AppName.csr
AppName.Key.pem
and also gave me a password for these.
The organization also gave me another certificate:
Organization.cert.pem
which is supposed to be used with their test tools.
The scenario is that the organization provided a test suite that runs on one vm, and the software I am building on another. I am supposed to import both of the certs into the vm with my software, and I think the organization's cert into the vm with the test software.
Problem is I don't know how, and the help links they provided are pointing to OpenSSL and some Java2SE tracing the secure requests/responses from either side....
Well, my code is written in C#, and both VM's use Windows Server 2008R2 x64 Standard/Enterprise. I am not sure how to import the certs, and configure them a) on a per application basis for a specific PORT and b) per domain basis?
Thanks,
Any help and guidance would be greatly appreciated!
Well, I downloaded the OpenSSL windows client and converted the AppName.cert.pem, AppName.csr AppName.Key.pem into a single consolidated AppName.PKCS12.
I later imported the result using the Cert Manager (MMC Snap In) in each WS2008R2 VM environment and it worked just fine.
It turns out that the Cert Manager also does understand what is a *.cert.pem file so I was able to import the Organization.cert.pem as well on both VM's.
Thanks
PS: Never read instructions about Windows config written by a Linux/Unix nut-job. This whole exercise of certificate management would've been easier if the person that wrote the test software manual (which I ported from Linux by the way...) didn't send me on a wild goose chase due to his lack of understanding of the capabilities of the Windows Server Environment... No need for OpenSSL.
<bleepzter/>