In my setup, i have a Sectigo EV code signing token plugged into my local (windows) machine. From that machine, i log in over RDP to another (windows) maching (in azure). On both machines, i have the "SafeNet Client" Software installed.
On the remote machine, i do run builds in as part of these builds .exe files and DLLs get signed using the cert on the token. This worked flawlessly for the last couple of years.
Lately, i had to renew the code signing token and at the same time, also got a new development (local) machine.
Now when i try to sign (using the same code/batch jobs, etc. like before), the signing fails, because the cert cannot be found on the remote machine.
i do remember having done something "special" for the signing to work a couple of years ago, but i do not remember if this was something with rdp configuration, a domain policy, a firewall policy or some configuration of the sectigo token.
I already asked the Sectigo support and they deny this setup is possible at all, which is clearly not true.
Any ideas what i need to tweak in order to be able use my previous singning setup again?
It appears nothing special has to be done, it 'just works'. I don't know why it did not work for me initially. However, i did uninstall the SafeNet Software on both the local machine and the remote machine and reinstalled. (First on the local machine, where the token is plugged in and next on the remote machine.)
No problems after that. No idea what caused the initial problems.
Related
Recently i have re-installed my GitLab application on my Linux system. When i tried to access my GitLab application link (https://gitlab.domain.com) on Windows system's Firefox browser i am getting below error.
Since the certificate generated freshly it was conflicting with existing/previous certificate, So i have followed this Link workaround. However even after system reboot also same error occurring, I can't access my GitLab application on Firefox browser.
I'm able to access it on Chrome browser without any problem.
Please let me know still where i need to clear the old certificate to make it work on firefox?
That seems to be the same error as in issue 435013 reported 13 years ago (and still open), where Firefox has an issue with routers and NSS (Network Security Services) (error -8054)
As I understand it, and from the discussion on #312732 which is the underlying issue, the problem is that the crypto uses the cert ID as a unique key in a database.
When a dupe is encountered, you can't have two primary keys in a database, so it just dies with a fatal error, hence FireFox gives up connecting to the site and passes on the fatal error to be presented.
This is not a "fundamental NSS design issue", it's a political issue, Firefox is ACTIVELY refusing to let people access their network equipment.
Check also the firmware of your router:
It seems to me that it is VERY EASY for the server-side products that
generate these certificates to more-or-less fix the problem in updated
firmware with very little effort. Even simply randomizing the serial numbers
in the certs, they would nearly completely eliminate the problem, AFAICT. In
fact, it is worth making sure that the affected server-side hardware has
up-to-date firmware, because some vendors might have already fixed it on
their end already.
Possible workaround (which would work even after FF restart)
This is hardly any fix, but I installed a new Mozilla from scratch on a VM under Virtualbox.
I than browsed to all my local systems I was getting this error. On connecting from the new Window3s sytem running on VM to each local IP, I received the warning, and created the exception.
I than went in to Preferences>Advanced, and Exported all the certificates to a share on one of my NAS units.
I proceeded back to the broken Mozilla running on my Mac OS X 10.11.1, and I Imported all the certificates.
I then restarted FF, and connected to each device I was getting the error on, and I received the "This is an untrusted connection, Get me out of here, or would you like to create an exception." YES!!
I created the exception, and finally I could get to my firewalls, and all other local devices.
Other workaround:
Run: firefox --no-remote --ProfileManager
Create a new profile there.
Open a new instance of Firefox using the new profile. To run Firefox with the profile you can use the command from 1. or: firefox --no-remote -P profile_name
Do the actions there as if it was a separate installation of Firefox
Microsoft SmartScreen, well-known for its message:
Windows Defender SmartScreen prevented an unrecognized app from starting
is useful for end users to avoid malware, but can also harm indie developers because when they distribute binaries: the end users see frightening messages, and that is a problem for the developer's reputation (see someone's comment "My customers often think that I am purveying a virus, malware or something illegitimate and they tell their friends and I lose sales"):
Smart-Screen filter still complains, despite I signed the executable, why?
Even with a paid certificate, if software-release1.0.1.exe is finally whitelisted, when you release software-release1.0.2.exe update, the messages will come again:
Transferring Microsoft SmartScreen reputation to renewed certificate
The only solution seems to be Extended "EV code signing" which can be 300-500$ per year (this fixed fee makes the tax % higher for small indie developers).
Question: is there a way to get a .exe whitelisted immediately (or a few days) for all users - and not only on my own computer - by submitting it to Microsoft for analysis?
I have seen this link: https://www.microsoft.com/en-us/wdsi/filesubmission, has someone been able to use it successfully to avoid further SmartScreen alerts? (it seems that no).
Are there other methods? Such as automatically deploying 100 VMs via an automated script, and let each VM download and install the .exe automatically? But this would probably be from the same IP, then Microsoft will probably increase the reputation counter by +1 instead of +100?
As you said in your question, the first solution for having trusted software is code signing with EV certificate But, another tricky solution is increasing reputation of your software. As Microsoft said here :
Reputation-based URL and app protection
If a URL, a file, an app, or a certificate has an established
reputation, users won't see any warnings. If, however, there's no
reputation, the item is marked as a higher risk and presents a warning
to the user.
So in the last paragraph of your question, you mentioned about creating mass docker containers or virtual machines for increasing trust and reputation. I complete it with a solution for same IP address in each VM or container.
The solution is using TOR as a proxy in all of your VM's or containers.
With using tor you can create proxy which is connected inside TOR network and hide your real IP address in your virtual machines or containers. Tor is free for use and you can connect your nodes to it's network as many as you want and change your IP address frequently. Also it is better to have different version of windows in some of your VM's. Remember before that you must submit your software for malware analysis,
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've installed a wildcard SSL certificate for two subdomains that I'm working on for an organization. This is the first time I've worked with wildcard certificates, and I missed installing the intermediate certificate when I first set this up, which resulted in certificate revocation messages when I first tried to load them. I've reloaded the certificates correctly, and both subdomains check out now using http://www.sslshopper.com/ssl-checker.html.
The sites appear to load fine everywhere except on the two machines (Mac Laptop & Vista Desktop) that I use to develop on, where they're still showing revoked. I've tried to refresh my local CRLs using the following commands:
certutil -setreg chain\ChainCacheResyncFiletime #now (Vista)
and
crlrefresh r p (mac)
I've restarted both computers and cleared browser caches but am still not able to access. How can I get my local machines to forget that the certificate was initially revoked?
I needed to ask the organization I'm working with to regenerate the certificate. I installed that one and everything's good to go now.
I'm currently developping a website with Visual Studio 2010 and IIS Express 7.5 on Windows 7 x64 in a VirtualBox VM.
I have followed this article and made it works like a charm.
Working with SSL at Development Time is easier with IISExpress
The problem comes when I shut down my machine and start it back the next day. It doesn't work anymore, I have to redo the whole opertations in order to make it work.
Does anyone has an idea why everything is screwed up each time I restart my machine?
Thanks in advance.
I've had this exact problem with full blown IIS 7.5 and Server 2008.
My particular problem came about when moving the server authentication certificate (and associated private key) around (through dragging) in the MMC Certificate Manager.
There's a step in the tutorial you linked to where they ask you to "drag" the certificate from Personal to Trusted Root Certificates. I'd suggest deleting that certificate from the Certificate Manager and importing it directly into the Trusted Root Certificates.
I had the same problem with a Code-signing private certificate, after reboot it was gone.
I found this on ServerFault:
Right-click the certificate in MMC console ->All Tasks-> Manage Private Keys.
Add the needed users to access Now, Reboot the system and try it will work.
enter image description here
Try editing the app.config as an administrator.
The other thing is you VM's hard drive might be writing changes to a read only delta which get's dropped when you restart, hence nothing is saved
Thias was the solution for me:
http://blogs.msdn.com/b/asiatech/archive/2013/03/25/case-study-ssl-does-not-work-in-iis-7-5-after-server-reboots.aspx
Delete the certificate from the computer store and import it again. Dont drag and drop it from the user store.