I am developing web app using Spring Boot and React. I want to deploy it on local server and make it accessible only through local network, but I want to make it secure, so I need SSL certificate to enable HTTPS. If I use self-signed certificate then I get error on clients browsers (not secure), because this certificate is not in their trust store. Is there any way to get certificate for localhost, I think that Let's Encrypt don't give certificates for localhost?
Generate Self signed root CA certificate.
Install your root CA in all client machines (enterprises root)
sign certificate with your root ca and install in web server
this certificate will be trusted.
I have a Windows image that uses the PowerShell execution policy AllSigned
I also have a PowerShell script that is signed by a signing certificate issued by an internal CA
The certificate of the issuing CA is installed/trusted on the target machine
When I sign the PowerShell script, I am including the full certificate chain (IncludeChain = 'All')
The certificate chain looks like this:
|- Issuing CA Certificate
|- Signing Certificate
The PowerShell script is signed by the Signing Certificate, but we are not installing that certificate on our target machine. We are only installing the Issuing CA Certificate into the Trusted Publishers and other certificate stores.
This method works when we sign our custom application binaries using the Signing Certificate (we use Windows Defender Application Control to ensure that any applications running on our target are signed by trusted publishers) but it does not work when running PowerShell scripts.
According to this MSDN community post, PowerShell uses Known Publisher rules, which state that the Signing Certificate itself has to be in the Trusted Publishers certificate store.
This is not ideal, as the signing certificate we use to sign the PowerShell scripts is not something we want to ship out, nor will it be valid anymore by the time our product ships.
I understand that if I use a timestamp server when signing the PowerShell scripts, that the signature will still be considered valid if the signature was generated within the validity window of the signing certificate, but this is not our preferred solution.
Ideally I would like to know if it is possible, and how, to have PowerShell use the Issuing CA Certificate to validate the signed PowerShell scripts. (i.e. Known Issuer rules)
In the case that it's not possible, I would like to know why Microsoft departed from the practice of allowing you to validate signatures without explicitly trusting the signing certificate (i.e. using the issuing certificate to validate it).
Any help would be greatly appreciated.
There is a difference between deployment and the running of PowerShell scripts.
The confusion is that Windows Defender Application Control can use code signing 2 different ways, for 2 different reasons, and PowerShell has only ever supported one. Windows Defender Application Control can use code signing:
With a trusted Issuing CA Certificate to authenticate applications. This is the situation when your company wants to share many internal applications among all employees easily. It is also used for "trusted" Microsoft Store applications.
Because "normal" people don't blindly trust all applications and generic certificate authorities, you can instead deploy based off of trusting just the Signing Certificate for verification. (see Catalog Files). This is so that you could deploy applications with certificates that may not have an accessible CA. e.g. if you singed the application with an internal CA and you sell it to another company, or if you are using a self signed certificate.
Windows Defender Application Control primary purpose is for Application deployment/control, and a byproduct is that it can do PowerShell scripts as well. Most "normal" applications can run with "invalid" or "broken" certificates with incomplete certificate chains. The certificate was only used to control the distribution of the code and validation that the application was not tampered with/changed, and has nothing to do with the active "running" of the code.
PowerShell, on the other hand, when running with AllSigned, always validates the entire chain before running. It doesn't care about the distribution, it cares about what it runs. That means that the entire certificate chain needs to be present and trusted on the running machine. Yes, that means that if you sign with an internal CA, you need the Issuing CA Certificate, and the Signing Certificate distributed and trusted by the running party.
This leads you to 3 options:
Self signed certificate - This is ok for personal/development projects, and marginally better than distributing unsigned code.
Internal CA certificate - This is ok for internal projects. In this case, yes, you would have to share the entire certificate chain if you wanted to distribute.
Global/Public CA Certificate - This is the recommended method if you are distributing publicly/commercially. The Public CA's are trusted, and code signing certificates can be bought from places like DigiCert and can last 3 years. I know, for me, I would feel much more comfortable running code signed by a DigiCert over having to mess with internal or self signed certificates.
That doesn't make sense.
If the internal root CA certificate is in your trusted root CA store and the intermediate in your trusted intermediate store. Then a PS script is signed by a certificate with a trusted chain back to the trusted root, it should trust the signing of the certificate.
There should be no difference between an internal trusted CA and a public trusted CA.
If anything a code signing certificate issued by an internal CA is more trustworthy than a public signed one. Internal processes and controls mean only actual trusted internal publsihers can get one, unlike a public code signing cert bought for a small amount.
I have a 3rd party development tool that was written in Golang. My company uses Netskope which injects self-signed certificates in any SSL traffic from my machine so they can monitor all traffic for security purposes. The application is failing with the error
"self signed certificate in certificate chain" when it tries to connect out to a site on the public internet, I assume because of these self-signed certificates in the chain
I found some comments that say the logic for certification verification on Windows can be found in https://go.dev/src/crypto/x509/root_windows.go, but I cannot find any documentation for Windows about this (only Linux). From looking at that code, my understanding is I need to have the CA certification set up in the local machine store as a Trusted Root CA but that isn't working for me. The screenshot here shows the CA certificates in my Local Machine trusted root CA store. I deploy to Linux containers, in JVM or other applications to allow them to trust these self-signed certificates.
Am I doing something wrong in setting up the CA certs in my Certificate Store? Is there any documentation on this? Is there another way I can configure on Windows any Golang application running on my machine to trust the CA for these self-signed certificates? I see on Linux you can similarly add the CA to your store, or use environment variables SSL_CERT_FILE and SSL_CERT_DIR, and I've been able to do this for other Golang applications in Linux containers.
I deploy my CA cert via GPO into Trusted Root Certification Authorities, which I can see is deployed to my client machines. I know this part is working as Chrome no longer moans when browsing to sites using my signed SSL certs.
However, when I try and git clone or push to any repositories behind an SSL cert signed by this CA, git-for-windows bawlks and says this:
schannel: next InitializeSecurityContext failed: Unknown error
(0x80092012) - The revocation function was unable to check revocation
for the certificate.
As you can see, I've got schannel enabled, but git-for-windows is clearly not reading my CA cert from the Certificate Store in Windows. Any one know how I make gfw read from the Certificate Store in Windows? I can't manually copy this cert onto all my Windows clients, that'd take forever.
Perhaps worth noting I'm using multiple Samba 4 instances as Domain Controllers, but I don't have access to Windows Server tools such as AS Certificate Services.
nb. I know I can disable tls verification, but that surely defeats the purpose.
I'm trying to configure my computer to trust a self-signed certificate for testing a website. However I'm having problems with Firefox. Chrome and IE are fine with it.
I've done the following.
Create a 2048 bit pem rsa key and crt with openssl
Created a pfx file from the key and crt files
Imported the pfx into the personal certificate store on the server using MMC
Configured IIS to use the certificate for the site
On the client PC
Imported the pem crt file into the personal certificate store with MMC
At this point Chrome is totally fine with the site and displays the green padlock. IE and Edge likewise show now warnings or errors.
However Firefox gives an SSL error and refuses to trust the certificate because it's self-signed.
I've tried creating the certificate as a CA and non-CA certificate, and it makes no difference.
I've also tried adding the certificate directly to Firefox's list of Authorities. It still won't trust it.
Is there some preferred method for convincing Firefox to trust a self-signed certificate? Is there some way to convince it that the certificate is not self-signed?
You must go to about:config and change the configuration
security.enterprise_roots.enabled to true.
https://wiki.mozilla.org/CA:AddRootToFirefox