How to show the publisher's name instead of "An unidentified program wants to access your computer" in vista?
You need to obtain a code-signing certificate (which is different from an SSL server certificate) from a certificate authority, and sign your programs with it. There are certain requirements for obtaining such a certificate; for example, some certificate authorities will require your company documentation, etc.
You need to sign your program with a digital signature.
Related
On WPF installer project build generates setup.exe and it is being signed using Signtool on PostBuldEvent. It does show Publisher as unknown on UAC popup at the very last step of setup.exe.
Can someone help me to fix this ?
MSI vs Setup.exe: You should sign the MSI file as well as the Setup.exe file.
Certificate Type: What kind of certificate are you using? I believe you need a digital code-signing certificate from a recognized issuing authority (DigiCert, Thawte, etc...).
EV-code signing certificate (please visit this link).
Why do I still see publisher unknown with the UAC prompt?
Get a code signing certificate
Signtool.exe: If you have a valid certificate, are you using the /d option to the command line of signtool.exe when signing your MSI?:
signtool.exe /d "Your Software Name"
How to add publisher in Installshield 2018
Trust Yet Verify: When you have signed the file, right click it and select "Properties" to make sure the file is actually successfully signed. Look for the tab "Digital Signatures" (or equivalent in your own language):
Administrative Installation: Sometimes people forget that they have run an MSI through an administrative installation. This is essentially a file extract from the MSI resulting in a new MSI without the embedded CABs in the output location (more). This extracted MSI will not be signed - even if the original MSI was signed. This extracted source is used in many companies to keep the installation files on a networks share available for repair and inspection (and during application packaging to inspect the package content - and other purposes).
Post-Processing MSI: This is actually a very common issue: you must never touch a file that has been digitally signed. If you edit it after the signature has been applied this invalidates the signature. The whole point of digital signatures is to verify that the file you look at is the one that was signed by the vendor. In other words that the file has not been changed in transit to you (tampering, malware infection, etc...). More on this important issue here (attempted humor in there). Note that the tampering might happen via automation scripts and not by manual editing, hence one must always check for this cause.
Other Issues: There are also some other possibilities. The signed file could be corrupted during download or from malware attack and such things. Far beyond the question, but just mentioned for whoever might find this.
Links:
Is it possible to define a Windows Installer-uninstaller filename?
Installshield Custom Dialogue Installer
How can i generate windows certificate so my msi doesn't shows warning to users
Further Links:
Windows printscreen not working on Software Installation
WIX-Installer MSI Publisher Unknown
Everything you need to know about Authenticode Code Signing
I would like to be able to sign my code, mainly just so windows defender won't complain about it on other computers but it needs to be signed nonetheless.
Convienently, visual studio provides an easy way to do that! Unless you're me...
https://i.stack.imgur.com/Ym2LM.png
The sign the click one manifests thing is unavaliable, and the sign the assembly, well, when I create a password key, well, lets just say it makes major uncircumventable roadblocks.
So my question is -
How can I sign my windows forms app, and why is what I would assume to be the tradional method greyed out?d
As far as I know/gotten-to signing software requires a x.509 certificate. I've never bought one or an SSL certificate for serving HTTPS, but I'm assuming they are similar, so maybe you can buy them at the same place...?
I just posted the Microsoft link Add an exclusion to Windows Security, it's the best I can do right now.
I am building a server/client application and I would like to use Microsoft's SSL instead of a 3rd party library such as OpenSSL.
I have came across this example code on the MSDN:
Server: https://learn.microsoft.com/en-us/windows/win32/secauthn/using-sspi-with-a-windows-sockets-server
Client: https://learn.microsoft.com/en-us/windows/win32/secauthn/using-sspi-with-a-windows-sockets-client
I am looking through the code and it appears that it is using a function AcquireCredentialsHandle which from my understanding just uses existing credentials (cert?) found on the system.
I would like to, if possible, create my own certificate on the fly each time I connect to the server. This way the cert is changed each time and if anyone were to get my cert then it would only be useful for the specific set of traffic.
I have two C binaries which tries to open network connection for communication.
This is for external communication. When i run that for the first time, OS X' firewall pops up the message as given in title. How can I get rid of this?
I suspect this is related to code-signing? How to do code-sign this binary?
Basically I have to build this binary in one Mac machine, and distribute outside app store.
How can I get rid of the firewall pop up if the OS X firewall is enabled in the machine?
You can resolve this by signing the offending application binary yourself.
Disclaimer: Signing an application yourself will make an application appear more
secure to the operating system, when in reality it isn’t. Only sign applications
that you are 100% sure are not spyware or otherwise malicious. If you have any
doubts, just uninstall/reinstall.
Part 1: Create a Signing Identity
The solution I’m going for – signing the app myself – requires that I create a Signing Identity, also known as Signing Certificate. This is very easy to do:
Open Applications > Utilities > Keychain Access.
From the Keychain Access menu, choose Certificate Assistant > Create a Certificate.
Fill in a name for the certificate. This name appears in the Keychain Access utility as the name of the certificate. This is also the name you will use when referencing this certificate. Personally, I used the name, “My Signing Identity.”
Choose Code Signing from the Certificate Type menu.
Choose Self Signed Root from the Type popup menu.
Check the Let me override defaults checkbox.
Click Continue.
Specify a serial number for the certificate. Any number will do as long as you have no other certificate with the same name and serial number.
Click Continue.
Fill in the information for the certificate. You can use real or fake data, I used real data personally.
Click Continue.
Accept the defaults for the rest of the dialogs.
Once completed, you will see your certificate in Keychain Access. Verify the name you picked, and you’re done with this step. Well done!
Step 2: (Re-)Sign your application
Now you have to sign your application. To do this, open up Terminal again and use the following command:
codesign -s "My Signing Identity" -f /path/to/your/binary/app
A dialog will appear, click "Allow".
Now start your application again. You will get the accept incoming connections dialog one last time. Click "Allow".
From now on you should no longer get the warnings anymore! Now it is possible to enjoy the security of your firewall being active without the inconvenience of having to click "allow" constantly.
Credit: The original source which served as a starting place for this updated and annotated solution guide was http://silvanolte.com/blog/2011/01/18/do-you-want-the-application-to-accept-incoming-network-connections/
In my case this alert appeared when i run Python project from PyCharm after updating MacOS to 10.15 Cataline. I fixed it with
codesign -vvv /Applications/PyCharm.app/
I was trying to apply this solution to fix python as used by Arduino OTA, I found another solution describing self-signing the app that stated $(which python) as the file path to sign, but in my case that resolved to /usr/bin/python. Self-signing this not only required I drop to Rootless mode to allow writing to /usr/bin, but when I went back and tested it, python was STILL asking for permission to allow incoming connections!
The correct python file to self-sign is in fact (in my case at least) /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app
Once I self-signed this correct file path, the Arduino OTA process no longer required me clicking allow incoming connections - Hoorah!
Hope that helps someone.
I have just started working with X.509 certificates. Can any one tell me how to go about validating a certificate on linux? The use case is that my app had downloaded a certificate in a previous session and I have to check if it is still valid (i.e., not expired or revoked since it was stored) before starting a new session. I understand a full sample will not be possible here, but any pointers will be useful.
EDIT: Further investigation revealed another utility called Network Security Services (NSS). How does that compare to OpenSSL in terms of usability? Also, I am looking for programmatic solutions as I will not be able to launch command line utilities.
As others mentioned, you can use openssl verify. According to the documentation, it also checks the validity period.
Programmatically, it could mean hours of searching for kinda bad (or missing) documentation, reading code examples all over the web, and probably a headache.
To properly validate a certificate, you need to inform all the intermediate certificates. Normally you'd also inform the revocation list (CRL), but it's not required.
So, here's what you need to do in terms of code (OpenSSL):
X509_STORE_new - Create a certificate store;
X509_STORE_CTX_new - Create a store context;
X509_STORE_add_cert - Add the CA (and all intermediary) certificate(s) to the trusted list of your certificate store (note: there's a function to lookup/load a list);
X509_STORE_add_crl - Add the revoked certificates to the CRL of your certificate store (note: same as above);
X509_STORE_CTX_init - Initialize your store context informing your certificate store;
X509_STORE_CTX_set_purpose - Define the purpose if you need so;
X509_STORE_CTX_set_cert- Tell the context which certificate you're going to validate;
X509_verify_cert - Finally, validate it;
X509_STORE_CTX_cleanup - If you want to reuse the context to validate another certificate, you clean it up and jump back to (5);
Last but not least, deallocate (1) and (2);
Alternatively, a quick validation can be done with X509_verify. However, be aware that it compares signatures solely.
When I needed it, took me a day of searching, reading and testing. Then I figured out everything I needed was right in the OpenSSL source-code. So, if you need an example, go straight to openssl-xxx/apps/verify.c.
IMPORTANT: NEVER use MD5. To understand the reason, read Creating a rogue CA certificate.
openssl verify will do what you want, if you want a simple tool:
From running:
cd /usr/share/ca-certificates
find . -type f -exec openssl -verify {} \;
Here's a selection of the output:
./telesec.de/deutsche-telekom-root-ca-2.crt: OK
./brasil.gov.br/brasil.gov.br.crt: OK
./cacert.org/cacert.org.crt: OK
./spi-inc.org/spi-ca-2003.crt: /C=US/ST=Indiana/L=Indianapolis/O=Software in the Public Interest/OU=hostmaster/CN=Certification Authority/emailAddress=hostmaster#spi-inc.org
error 10 at 0 depth lookup:certificate has expired
OK
./spi-inc.org/spi-cacert-2008.crt: OK
./signet.pl/signet_ocspklasa3_pem.crt: /C=PL/O=TP Internet Sp. z o.o./CN=CC Signet - CA Klasa 3/serialNumber=Numer wpisu: 4
error 2 at 1 depth lookup:unable to get issuer certificate
./signet.pl/signet_ca3_pem.crt: /C=PL/O=TP Internet Sp. z o.o./CN=CC Signet - CA Klasa 3/serialNumber=Numer wpisu: 4
error 20 at 0 depth lookup:unable to get local issuer certificate
If you'd rather have the results in a larger program, perhaps the gnutls_x509_crt_verify(3), gnutls_x509_crt_get_key_usage(3), gnutls_x509_crt_check_revocation(3) interfaces are easier to use than OpenSSL. (I've never used gnutls, but I have used OpenSSL.)
OCSP is a protocol to check revocation of certificates. Openssl provides certificate chain validation and signature verification APIs. It requires some amount of coding. So i would suggest you to look into Openssl Documentation.
You have to pass the certificate chain and validate it until you reach a root certificate which should be already saved on your machine. This is self signed certificate issued by entities called Root CAs(Certificate authority)
Apart from OCSP there is a outdated method where you have to fetch revocation list namely CRLs and parse that list for the certificate id.
EDIT:
I forgot to mention the openssl command line utility which does the same functionality.