I need to trust an SSL certificate on my windows machine, however, the ways I've tried don't work properly. My problem is the CommonName on the certificate is the name of my machine, not the issuer. Invalidating the access by browser;
My machine:
Device name DESKTOP-B3XXXXX
Processor Intel(R) Core(TM) i7-10750H CPU#2.60GHz 2.59GHz
Installed RAM 16,0 GB (15,8 GB usable)
System type 64-bit operating system, x64-based processor
Edition Windows 10 Pro
Version 22H2
Installed on 24/06/2022
OS build 19045.2486
Experience Windows Feature Experience Pack 120.2212.4190.0
About the certificate:
Version: V3
Signature Algorithm: sha256rsa
issuer: local.example.dev //changed to 'example' here on stackoverflow
Public Key: RSA (2048 Bits)
Subject Alt. Name: DNS Name=local.example.dev
Was generated by the team. My teammates was able to install it on their mac, and the other dev who is using windows, was able to trust on the same .crt;
The methods that I tried to install:
Double click on .crt file and Follow the wizard. In this method, I tried with the following options: Current User/Local Machine and Automatically select the certificate store ... and `Place all certificates in the following store: Trusted Root Certification Authorities;
Open mmc.exe program. Click on File>Add/Remove Snap-In, then Certificates>Add>Computer/My User Account. Finally, right click on Trusted Root Certification Authorities and selected All Tasks/Import...;
Removed all installed certificates, and add again by mmc.exe in method 2;
But still getting the wrong certificate in any browser. I tested chrome, firefox and edge; Inspecting the certificate used by them, show a certificate with CommomName with my computer name DESKTOP-B3XXXXX.
Related
Supporting older Windows versions in apps and drivers has become much more difficult due to MS policies/actions and Certificate Authorities (issuers) following them. At this point it looks like we have to create our own self-signed SHA1 certificate and install that in the Trusted Publishers store on the end-users machine. Also, cross-signing of drivers for OSes prior to Win10 is expired and no longer available as an option. That means normal signing will need to be used and both the SHA2 and SHA1 certificate being added to the Trusted Publishers store on the end-user machine.
Catch 22 - while creating a mini certmgr type tool would be easy, there is no way to sign it for SHA1/SHA2 so the OS sees a valid signature before installing the certificates to the store. Had this utility been created a couple years it could have been signed with the SHA1/SHA2 certificates that worked at that time. certmgr (SDK 8.1) however is double-signed with SHA1/SHA2...
Now the question I have is if we were to sign the apps with the valid SHA2 EV certificate and the SHA1 self-signed certificate so that the SHA2 EV is "valid" (on Win Vista or later) and the SHA1 is "invalid" (because certificate is not in the store) will that throw off Anti-virus software or Windows itself or are they smart enough to see the SHA2 EV is "valid" so it's valid?
Same with drivers (on OSes prior to win10) (Win10 are signed by MS and while the SHA2 signature is good, the .cat file has no reference to prior OS versions - only Win10/11 are available in the MS portal)? Although drivers wouldn't be installed prior to installation of the certificate.
The question comes up because we would like to only install the SHA1 certificate to the store on old OSes (Prior to Vista) that may still use SHA1 and leave it off the newer OS versions (meaning it's invalid)? But we wonder what problems / confusion with other software / Windows could that create?
Comment: Since Windows can simply ignore SHA1, it seems there should have been no reason to prevent the CA's from issuing SHA1 certificates to make it easy to support the old OS. The same applies to the cross-signing of drivers, new versions of Windows could simply ignore those and only support the MS signed version (like it already does for Win10/11 - this would allow updates to drivers for Win7, etc..). These changes are what everyone was worried about when all the certificate requirement stuff was being proposed. They ensured everyone this wouldn't happen...
Since you can no longer obtain an SHA1 certificate from the normal certificate authorities, even if you want one (because MS told them they can't), I've created a self-signed certificate following this but using sha1. I can have my CA certificate installed so certificate works fine. But for drivers, specifically 2K/XP prior to SP3, I need to cross sign it with the /ac option. Is there anyway to do that or is that whole platform now going to be hard to support any driver updates without users having to disable driver certificate requirements?
I'm trying to load a kernel driver that's been signed with a certificate generated by MakeCert.exe.
I followed the instructions given in the Windows Driver Kit documentation:
Sign the driver with MakeCert.exe
Verify the signature with SignTool verify /v /pa DriverFileName.sys.
Installing the cert into the test computer's Trusted Root Certification Authorities store and Trusted Publishers store, using CertMgr.exe
When I verify the signature with SignTool verify /v /pa DriverFileName.sys as described in WDK Microsoft Docs, SignTool reports that the signature is ok. I've done this on both the development computer and the test machine that is supposed to load the driver.
However, the driver doesn't actually load. The Windows CodeIntegrity log says 3004: Windows is unable to verify the image integrity of the file \Device\HarddiskVolume3\path\DriverFileName.sys because file hash could not be found on the system. 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.
I looked at this similar question. I get the same results as in that question, when I run SignTool verify /v /kp DriverFileName.sys. It says: SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
The linked question's resolution involved using a real, non-test certificate, and changing the signing setup so that it correctly chained to the Microsoft Root Certificate. I'm not yet at that stage; I just want to get my test infrastructure working "properly".
I'm interested in having the kernel load my driver, and verify the signature using the certificates that I've manually installed on the test machine. I know I can use bcdedit -set testsigning yes to disable signature validation entirely, but that seems like overkill - it will allow any signed driver to run, even if it wasn't signed with the test certificate I've installed on the machines. Is it possible to leave "testsigning" mode turned off (so the driver signature is still actually validated against an installed cert), but still use my internal self-generated MakeCert.exe test certificate?
It looks the answer is no, it's not possible.
Can I install self-signed drivers on 64-bit Windows without test mode if the self-signed CA root certificate is imported to the machine store?
The WDK documentation seems quite misleading. Installing the certificate generated by MakeCert.exe on x64 test machines seems to be entirely pointless, since the kernel never pays any attention to it.
If TESTSIGNING mode is on, the signature isn't validated, so the cert doesn't need to be installed.
If TESTSIGNING mode is off, the self-signed certificate isn't cross-signed by anything the kernel trusts, so it's not considered valid, so installing the cert doesn't help.
I'm happy to accept corrections.
I am trying to code sign a driver in Windows (drivers for a video capture card). I have the inf, cat, sys files for this driver. I have followed various Windows articles and so far am able to:
1) Download a "DER" file from GoDaddy and then create a "mycompanyinc.cer"
2) Use signtool to sign the .cat, .sys drivers
3) verified the .cat, .sys driver files are updated with digital certifiates.They correctly stated that its issued to "my company" and issued by "go daddy CA". I exported the above certificate to a ".cer" and put on a different computer
I used MMC to make sure it shows up in the Trusted Root Certificate Authorities on the system where I need to install the drivers. While there driver file shows correctly the information "issued by" ,"issued to" etc. Windows is still complaining during drivers install that the digital signature can't be verified.
Any help, direction in this matter will be greatly appreciated.
thanks!
Since 2016 Microsoft require a longer process along with an EV Code Signing Certificate for signing drivers.
They explain it in this article.
Today I spent the whole day investigating why I have so many problems with WebDAV.
My Server is running Windows 2008 R2 with IIS7.5.
I created a self signed certificate and added it to the "Default Web Site". I enabled Windows Authentication and installed the WebDAV Extension.
I enabled Locking WebDAV Settings as you see here:
http://www.abload.de/img/webdavydkea.png
I then created a folder called Shares on C:\ and changed added writting permissions for the domain users.
At the end I created the Virtual Directory and set the "Authorization Rules" and the "WebDav Authorization Rules".
At the end I force the usage of SSL with the previously self signed certificate.
Now I try to connect with MAC OS X 10.7 and MAC OS X 10.6 and both mount it readonly.
If I try to mount it in Windows I get the following error message:
The mapped network drive could not be created because the following error has occurred:
A device attached to the system is not functioning.
More details if I try to mount it by using the command line:
System error 1244 has occurred.
The operation being requested was not performed because the user has not been authenticated.
If I now disable the SSL support I can mount it in Windows too including write support. MAC OS X still does only mount it as read only.
Altogether I have the following problems:
Why does MAC OS X mount the WebDAV directory as readonly even so I enabled locking support?
Why does Windows not work if I try to use SSL with the self signed certificate?
I have a similar setup, and just experienced the same "cannot connect from Windows 7" problem.
I found that I can connect from a Win XP machine. On connecting, a popup asks me if I want to trust the self-signed cert -> I accept -> it connects well.
This made me suspect that the Win 7 problem is with the cert (with not showing a popup to let me manually accept the self-signed cert). The solution to make it work is:
Either import the self-signed cert in Win 7 / IE9 into the "Trusted root CA"
cert store.
Or buy a cert that is signed by a known cert authority.