I'm using CAPICOM to load a certificate needed by a WebService client.
I need to have the certificate installed in Windows, and then open it from the certificate file itself, which I think is "kinda stupid".
Is there any way to either (in order of preference):
Save the PFX File contents to a memo field in the database, and load it from there, without installing it on Windows?
Load the PFX File from the file itself, without installing it on Windows
I'm using Delphi XE3, LibEay32 and Capicom 2.0
If you want to install the certificate in Windows you will ALWAYS get a popup asking the user for permission, unless the certificate comes from a root that is already trusted. If you don't want that the only option is to use the PFX contents from a memo field each time you need the certificate.
I have no experience with Capicom, but from what I read it is a Microsoft DLL that you use?
If you are having problems with Capicom and LibEay32 you might want to check out the Eldos Secure BlackBox components. I have very good experiences with those and their support is great.
Related
I need to install a cert to allow a browser to talk to localhost via our app. The .pfx file created for this purpose works great when imported with the Windows 10 MMC tool. But that's a lot of steps to make our users do manually.
By following the steps in this answer (Install a pfx certificate in a users store in Windows using WiX), I can build an MSI and it runs on the target machine without errors.
However, the cert does not exist in the usual "Certificates - Local Computer" MMC tool, nor can the cert be bound to the app with netsh. After a bit of searching, it turns out the cert is installed "somewhere in IIS", and is only visible in the IIS tool (?!).
Using openssl, I converted the .pfx to a .pem file. When running the MSI, this DOES seem to install the cert to the proper place (?!). However, the cert is missing the private key, so it also can't be bound with netsh ('SSL Certificate add failed, Error 1312').
What on earth is going on, and how can I make Wix install the certificate properly?
Well, I guess I figured it out. I tried running the MSI on a virgin Windows 10 installation, and the .pfx file installed correctly and can be bound ok.
So, my guess is that "something" is checking the local computer to see if IIS is installed, and makes the decision to install the cert in a place that only IIS can see or use it. There's probably a lot more going on behind the scenes, but that's the gist of it.
In summary, use a .pfx file to get the private key, and remember that the installation will only work on computers without IIS installed.
I have acquired and deployed a digital code signing certificate. I have added it to the installation program for a Windows application, signing the InstallShield setup.exe file and the msi file. Everything works perfectly in the installation program.
My application is installed as a single exe file along with a complied html help file.
Is the best practice to digitally sign the exe file in addition to the Windows installation program?
Yes. You should sign the executable as well.
You should also ensure you use a time-stamp server if possible when signing too. Thus users of your application know the code came from a valid source, and the certificate was valid when it was signed. (The time-stamping means users can check the signing is valid after the expiry date of your certificate - i.e. the signature will be valid for all time.)
I'm unclear how a driver should be signed in my specific circumstances.
OpenVPN has a tap driver that consists of tap0901.sys, tap0901.cat and OemWin2k.inf files.
When I install it using "devcon install OemWin2k.inf tap0901" on my win7 64-bit, it installs silently, without scary warnings.
I renamed the driver to have a different name ogtap100 (by renaming files to ogtap100.sys, ogtap100.cat and replacing "tap0901" strings in OemWin2k.inf to "ogtap100", as per http://community.openvpn.net/openvpn/wiki/ManagingWindowsTAPDrivers and comments in OemWin2k.inf).
However, when I run "devcon install OemWin2k.info ogtap100" on the renamed driver, I get big scary warning from Windows that the driver comes from unknown source. It'll install but I plan to ship it as part of my app, so big scary warning is not good.
When I run "signtool verify /v ogtap100.cat", I get: "SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." even though it also says that root certificate is "Issued to: DigiCert High Assurance EV Root CA".
I've tried re-signing (signtool sign /f cert.pfx ogtap100.cat) with my own certificate (which works when signing regular .exe files) but I get the same scary warning.
What am I missing?
Can it be sth. to do with catalog (.cat) file?
I've read http://msdn.microsoft.com/en-us/windows/hardware/gg463050 but it assumes that I'll generate .cat file myself. I already have .cat file from OpenVPN. Do I have to re-generate it after renaming files and OewmWin2k.inf? If yes, how?
1) Did you ensure that you got the high assurance digicert certificate? The standard one they issue isn't meant for drivers. It is simple to change...
https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm
2) If you download the Windows 7 DDK and do a little 'reading the intent and the code' as opposed to just following the instructions, you can succeed at building your own driver (cat and sys files), properly renamed and signed.
https://community.openvpn.net/openvpn/wiki/BuildingTapWindows
Look at the OemWin2k.inf generated for some strong hints for renaming. Note: The Time stamp needs to be correct, and it is in (the ridiculous) mm/dd/yyyy format.
3) As for the warning message, at least you can get it to properly display your company name, and Windows will accept (and not disable) the properly signed driver.
For details about driver signing, check out
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/0b00c9d4-dff9-4fbe-b741-768c9b39349c/practical-windows-code-and-driver-signing-discussion?forum=wdk
This is a summery that points to some reference docs. Generating the .cat file from the inf is simple.
Check out the syntax and order of operation. I'm also using a Digicert certificate. make sure you have one issued for driver signing and pay attention to the make sure the cross certificate is correct.
The build script uses the inf2cat method, so if you are following the WHOLE instructions (and searching for the stuff in the settings that the inf didn't tell you about ... look for constants) then you are generating the .cat file.
For my install, I figured that the .sys file should be signed before generating the .cat and signing it.
Also, make sure your pc has all the windows updates. This actually did work to 'fix' a pc that had the same error signature. (It didn't have the required certificate to validate the cross certificate, which it automatically downloaded.)
On my machine, I’m using a signed application with an installed certificate to get a trusted publisher dialog from Windows. I’ve created a certificate with makecert.exe and installed it to the certification store in windows. From there, I’ve exported the PFX and signed with signtool.exe my application. In order to get the same trusted publisher dialog on another machine, a certificate is necessary. Instead of installing the certificate by hand, an installer should accomplish the importation of the certificate. Unfortunately, the windows installer doesn’t support this feature. Because of that, I’m looking for a solution like a classical API command in windows. Is there something built-in in windows to make it easier or something comparable?
To install certificate with respect of MSI setup you have to use custom actions. If you not familiar with custom actions I recommend you to use the simplest custom action which allows you to start an exe. It can be an existing utility like CertUtil.exe (see here some examples and try certutil -importPFX -? to see help about the import of PFX files).
I'm working to upgrade our source control from hg 1.6.0 to 1.8.2 and I'm looking to set up and use SSL certs. This is on a Windows Server 2008 Enterprise system running IIS 6.0, not my server so I need to use those versions of software right now. All my users are running Windows too.
To ease installation/configuration for my users I'd prefer to modify the Windows Cert Store instead of the cacert.pem file. Does Mercurial have access to the Windows Certificate Store? It doesn't seem to. I am using internally created certificates and I can get things to work without SSL warnings by adding my root cert to the cacert.pem file in Mercurial but I can't seem to get it to work by adding the certs to the Windows Cert Store. Am I missing something?
Thanks,
Scott
No, Mercurial does not access the Windows certificate store.
It includes in its distribution a cacert.pm (as you know, even though before 1.7.3, the story was a bit different)
The article "X.509 certificates and Mercurial" has more information.
A principal thing to remember here is that Mercurial will not work as a complete server out of the box, requesting authentication information, in the form of basic, digest, or certificates, at all.
This means that in order to use X.509 certificates with Mercurial, one needs to place a web server that knows of these authentication mechanisms in front of it.
This article includes makecert.exe, which actually knows about the Windows certificates store (contrary to Mercurial itself)
makecert.exe is a bit of a different beast from openssl as it interfaces directly with the machine’s or user’s certificate store (the special place where certificates live a happy life in Windows).