I'm trying to deploy a VSTO solution, which are 2 addins for Word and for Outlook, using ClickOnce. Due to our deployment infrastructure/practices, I cannot publish it using Visual Studio, it is instead built on a build server and deployed via a deployment server.
For local development, a self-signed certificate is used. The deployment worked with this self-signed certificate (if the the self-signed certificate was installed on the machine), but now I want to add a real company certificate so that the application can be deployed to the users.
During deployment, after the configuration files are poked, they are updated and re-signed with the real certificate. However, this produces the following error during installation:
System.Security.SecurityException: Customized functionality in this application will not work because the certificate used to sign the deployment manifest for <app name> or its location is not trusted. Contact your administrator for further assistance.
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInTrustEvaluator.VerifyTrustPromptKeyInternal(ClickOnceTrustPromptKeyValue promptKeyValue, DeploymentSignatureInformation signatureInformation, String productName, TrustStatus status)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInTrustEvaluator.VerifyTrustUsingPromptKey(Uri manifest, DeploymentSignatureInformation signatureInformation, String productName, TrustStatus status)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInTrustEvaluator.VerifyTrustUsingPromptKey(Uri manifest, DeploymentSignatureInformation signatureInformation, String productName)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.ProcessSHA1Manifest(ActivationContext context, DeploymentSignatureInformation signatureInformation, PermissionSet permissionsRequested, Uri manifest, ManifestSignatureInformationCollection signatures, AddInInstallationStatus installState)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.VerifySecurity(ActivationContext context, Uri manifest, AddInInstallationStatus installState)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
The Zone of the assembly that failed was:
MyComputer
The only lead I have is that, after re-signing, the values in publisherIdentity element are not changed (both .vsto and .manifest), only the Signature element has values corresponding to the new certificate.
Following commands are used to sign the .vsto and .manifest files (as far as I can see from the deployment scripts):
mage.exe -Update "[path to .vsto/.manifest]"
mage.exe -Sign "[path to .vsto/.manifest]" -CertHash [certificateHash]
where [certificateHash] is the thumbprint of the real certificate and is used to look up the certificate in certificates stores. I'm told this is security measure so that the certificate file doesn't have to be distributed along with the deployment package.
After signing, the files have their Signature values changed, but the publisherIdentity still has the name and issuerKeyHash of the self-signed certificate.
I tried poking these two values prior to re-signing, but I'm don't know how to calculate the issuerKeyHash.
Any advise on how to proceed would be much appreciated!
Edit:
I was trying out other mage.exe parameters, like '-TrustLevel FullTrust' (which didn't have any effect) or '-UseManifestForTrust True' along with Name and Publisher parameters, which yielded this error message (which is different than the one mentioned above).
************** Exception Text **************
System.InvalidOperationException: You cannot specify a <useManifestForTrust> element for a ClickOnce application that specifies a custom host.
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.GetManifests(TimeSpan timeout)
at Microsoft.VisualStudio.Tools.Applications.Deployment.ClickOnceAddInDeploymentManager.InstallAddIn()
.
The certificate that the app is signed with isn't trusted by Windows. As a work around,
Right click on setup.exe,
Select properties then the Digital Signatures tab
Select Vellaichamy/user then click Details
Click View Certificate and Click Install Certificate.
Do not let it automatically choose where to store the sert, install the certificate in the Trusted Root Certification Authorities Store. Once the cert is installed the app should install...
Take a look at the Granting Trust to Office Solutions article which states the following:
If you sign the solution with a known and trusted certificate, the solution will automatically be installed without prompting the end user to make a trust decision. After a certificate is obtained, the certificate must be explicitly trusted by adding it to the Trusted Publishers list.
For more information, see How to: Add a Trusted Publisher to a Client Computer for ClickOnce Applications.
Also you may find the Deploying an Office Solution by Using ClickOnce article helpful.
We have found what the problem was. We used a version of mage.exe tool from Windows SDK from a folder named 7A (I don't remember the full paths, sorry). A colleague then found another folder with versions 7A, 8 and 8A. Once we took the .exe from 8A folder, the installation works as expected.
Try copying all the necessary files to the client computer then install. If you can avoid installing from the network drive you might be able to avoid this exception.
Related
I installed the GitHub copilot but the extension do not work, always show the following error :
What could I do to solve this ?
Copilot error: “GitHub Copilot could not connect to server. Extension activation failed: self-signed certificate in certificate chain” is generally caused using CoPilot behind a Corporate network.
Most corporate networks have a ‘Man-in-the-middle’ appliance that dynamically breaks open all secure SSL traffic leaving home to enter the internet. This ensures they can inspected any traffic leaving, including your online banking. Usually automation scrubs the traffic looking for theft of company secrets or IP and raises alerts. It all gets logged and reviewed further if need be.
This action leaves behind a fake cert chain as a fingerprint. The cert for the called site is replaced with a fake, and one signed by the company’s own private CA authority. Hence the self-signed cert in the cert chain error.
From any company device (Phones\Laptop) the company CA is already installed as a trusted CA. So the local browsers and other desktop apps trust this faked cert chain - and so do not raise any concerns someone is snooping your secure network traffic (the company does own the network and the device).
By default VSCode is not trusting the installed desktop certs, and so it noticed that the GitHub cert is no longer signed by a trusted public CA authority.
As Rypox states above, the VSCode extension ‘Win-CA’ (must be set to ‘append’ mode) solves this issue. It tells VSCode to also trust the CA’s installed on the employees desktop. This makes VSCode happy again trusting the fake cert chain. No 'whitelisting' needed and not 'VPN' related. But certinly not that obvious either. An interesting CA trust issue.
Confirming this does exist is easy from your browser. Go to any outside site (like Amazon) and review the sites “Cert” to see who the CA’s are (Certification Path). It should ‘not’ contain any reference to your company. Look at that same cert from outside the company network on your own personal laptop.
… “bit of a glitch in the Matrix”, installing Win-CA helps hides it again and all looks back to normal.
Had the same issue with a corporate proxy, the win-ca extension resolved it.
In settings switch to append mode (it's not the default)
Restart VsCode
PS: this is a windows only solution (for mac see another post - self signed certificate in certificate chain on github copilot)
On macOS, you can use this script to monkey patch the Copilot extension to make this work:
_VSCODEDIR="$HOME/.vscode/extensions"
_COPILOTDIR=$(ls "${_VSCODEDIR}" | grep -E "github.copilot-[1-9].*" | sort -V | tail -n1) # For copilot
_COPILOTDEVDIR=$(ls "${_VSCODEDIR}" | grep "github.copilot-nightly-" | sort -V | tail -n1) # For copilot-nightly
_EXTENSIONFILEPATH="${_VSCODEDIR}/${_COPILOTDIR}/dist/extension.js"
_DEVEXTENSIONFILEPATH="${_VSCODEDIR}/${_COPILOTDEVDIR}/dist/extension.js"
if [[ -f "$_EXTENSIONFILEPATH" ]]; then
echo "Found Copilot Extension, applying 'rejectUnauthorized' patches to '$_EXTENSIONFILEPATH'..."
perl -pi -e 's/,rejectUnauthorized:[a-z]}(?!})/,rejectUnauthorized:false}/g' ${_EXTENSIONFILEPATH}
sed -i.bak 's/d={...l,/d={...l,rejectUnauthorized:false,/g' ${_EXTENSIONFILEPATH}
else
echo "Couldn't find the extension.js file for Copilot, please verify paths and try again or ignore if you don't have Copilot..."
fi
if [[ -f "$_DEVEXTENSIONFILEPATH" ]]; then
echo "Found Copilot-Nightly Extension, applying 'rejectUnauthorized' patches to '$_DEVEXTENSIONFILEPATH'..."
perl -pi -e 's/,rejectUnauthorized:[a-z]}(?!})/,rejectUnauthorized:false}/g' ${_DEVEXTENSIONFILEPATH}
sed -i.bak 's/d={...l,/d={...l,rejectUnauthorized:false,/g' ${_DEVEXTENSIONFILEPATH}
else
echo "Couldn't find the extension.js file for Copilot-Nightly, please verify paths and try again or ignore if you don't have Copilot-Nightly..."
fi
Save as something like monkey-patch-copilot.sh, then chmod +x monkey-patch-copilot.sh. You should then be able to run: ./monkey-patch-copilot.sh to apply the patch.
Note: I am not the original author. This was found on the Copilot feedback forum.
For any MacOS users, the VSCode extension linhmtran168.mac-ca-vscode can help as well with this. It is similar to the previously mentioned win-ca.
https://marketplace.visualstudio.com/items?itemName=linhmtran168.mac-ca-vscode
This looks like a similar error to what I am getting. I believe that the source of this in our corporate network is a ssl inspection process such that when the https traffic is opened and inspected that it breaks the certificate chain and this error shows up. A fix would be to add the GitHub Copilot servers to the ssl inspection whitelist so that that traffic is not inspected.
Corporate VPN was the problem (same as #mark-derry's).
Jetbrain's PyCharm / DataSpell allows to accept self signed certificates.
VSCode doesn't seem to have this option yet.
I found a solution for this which works for me in case of Intellij. I have blogged about it at https://sidd.io/2023/01/github-copilot-self-signed-cert-issue/
At a high level I think the architecture of the plugin might be same :
IDE Native CoPilot Plugin ---making RPC call---> NodeJS based CoPilot Agent
And this NodeJS based CoPilot Agent agent has issues with the Self Signed Certs (at least in my case).
Fix is as follows :
Export the self-signed certificate in discussion
Convert it into .pem format if not already
Export the path of this .pem cert to NODE_EXTRA_CA_CERTS variable
Restart your IDE and it should work
Easy!
Method 1 : just excute this code.
git config --global http.sslVerify false
Method 2:
FOllow this guide! and Thank me later because I have saved you a time of husel ? :) . you're welcome!
https://mattferderer.com/fix-git-self-signed-certificate-in-certificate-chain-on-windows
I have owncloud version 9.1.8 running on a synology. Now I installed onlyoffice on a local server with a self signed certificat. It is important to know, that the onlyoffice server is running locally in a network. So I cannot access the server like e.g. with lets encrypt, because I only have a local server name and not a public server name. Lets Encrypt therefore cannot verify the server. However if I want (and if you have a solution doing that), I can access the internet using the server.
Now i have the problem, that owncloud delivers me the following error message
"Error while downloading the document file to be converted."
when I want to save the url in the onlyoffice configuration in owncloud. I guess the problem is, that I am using a self signed certificat. Do you know what I can do? Google does not really help me.
"Error while downloading the document file to be converted."
means that DocumentServer cannot validate your storage's self-signed certificate (OC in your case)
There are 2 possible workarounds:
1) Change "rejectUnauthorized" to false in the /etc/onlyoffice/documentserver/default.json config file
2) Change the default Node.js CAstore:
Edit the files:
/etc/supervisor/conf.d/onlyoffice-documentserver-converter.conf
/etc/supervisor/conf.d/onlyoffice-documentserver-docservice.conf
Add a flag --use-openssl-ca to the parameters in this line
Then you need to add your certificate to the the default CA store and restart ONLYOFFICE services:
supervisorctl restart all
In PostgreSQL, whenever I execute an API URL with secure connection with query
like below
select *
from http_get('https://url......');
I get an error
SSL certificate problem: unable to get local issuer certificate
For this I have already placed a SSL folder in my azure database installation file at following path
C:\Program Files\PostgreSQL\9.6\ssl\certs
What should I do to get rid of this? Is there any SSL extension available, or do I require configuration changes or any other effort?
Please let me know the possible solutions for it.
A few questions...
First, are you using this contrib module: https://github.com/pramsey/pgsql-http ?
Is the server that serves https://url....... using a self-signed (or invalid) certificate?
If the answer to those two questions is "yes" then you may not be able to use that contrib module without some modification. I'm not sure how limited your access is to PostgreSQL in Azure, but if you can install your own C-based contrib modules there is some hope...
pgsql-http only exposes certain CURLOPTs (see: https://github.com/pramsey/pgsql-http#curl-options) values which are settable with http_set_curlopt()
For endpoints using self-signed certificates, I expect the CURLOPT you'll want to include support for to ignore SSL errors is CURLOPT_SSL_VERIFYPEER
If there are other issues like SSL/TLS protocol or cipher mismatches, there are other CURLOPTs that can be patched-in, but those also are not available without customization of the contrib module.
I don't think anything in your
C:\Program Files\PostgreSQL\9.6\ssl\certs
folder has any effect on the http_get() functionality.
If you don't want to get your hands dirty compiling and installing custom contrib modules, you can create an issue on the github page of the maintainer and see if it gets picked up.
You might also take a peek at https://github.com/pramsey/pgsql-http#why-this-is-a-bad-idea because the author of the module makes several very good points to consider.
Profiles installed by MDM service are showing as "Not Verified" after upgrading the device to iOS 6. These profiles were signed by a InCommon cert issued by AddTrust before being pushed to the devices. They were showing as "Verified" before the upgrade. Any ideas what might have caused this?
I got exactly the same problem so it is probably a bug in the iOS profile system because the very same SSL certificate is trusted by the browser. Note: Our certificate is of the "*.host.org" type.
This might be an untrusted CA in the certificate chain from the cert provider you bought it from. Looks like some CAs are untrusted or missing from iOS6. I had the same problem and included the whole of the cert chain in our cert signing bundle and the issue was resolved.
Suggest you open a support case with your cert provider to see if it's a known issue or dig around to see if you can find a list of trusted CAs used in iOS6 - I couldn't find one. Synching the device to iTunes may also refresh the CA list but this didn't work for me this time.
I have exactly the same problem as your.
My chain is GeoTrust -> RapidSSL -> MyCert. I have included the full chain in my .crt, but it stills show "not verified" when I try to install the configuration profil.
I don't know how to insert the whole path.
I use an openssl command to sign my file :
openssl smime -sign -signer #{crt_path} -inkey #{private_key_path} -nodetach -outform der -in #{file_to_sign_path} -out #{file_signed_path}
My crt_path is a .crt file, including the three certs.
EDIT
I found out the problem with my openssl command. My full chain was in the #{crt_path} but was not used by the command. I added the *-certfile #{crt_path}* and things works well !
Including the intermediate cert in the pkcs7_sign call (php openssl_pkcs7_sign() in my case) revolved the problem.
Yes! Adding the entire path (-root) did the trick.
Verify that the signature created by the MDM SW actually contains the path. Since it wasn't needed before...
Upon installation of a client side certificate, I am getting the exception "Object contains only the public half of a key pair. A private key must also be provided". My application is a VC#.NET application running over an ASP.NET platform. The application also uses WSE 2.0 to import certificates into making SOAP requests.
Upon research, I've found that this exception is of type System.Security.Cryptography.CryptographicException.
I am pretty positive all my WSE settings are configured correctly, since I was able to find a similar certificate by subject-distinguished-name. Any ideas will be greatly appreciated.
I was recently having the same problem. I found one explanation here that worked for me. Specifically, the permissions for the private key. The full info is copied below.
There are a couple things that I would
look at first:
Do you have a private key for this certificate?
Have you given permission for youf application to access the private
key?
You can establish whether you have a
private key by viewing the certificate
through the Windows Certificate Store.
To get to this, follow these steps:
From the Windows Start menu, select Run.
Type mmc in the Open: field. Click OK
Select "Add/Remove Snap-in" from the File menu.
Click the Add button.
Select "Certificates" from the list of Available Standalone Snap-ins.
Click the Add button.
Select "Computer account." Click Next.
Select "Local Computer". Click Finish.
Click Close.
Click OK.
Expand the Certificates node under the Console Root and open the
Personal store.
Double-click the Certificate you're using. If you have a private
key, the dialog will display a message
at the bottom that says "You have a
private key that corresponds to this
certificate".
If you have a private key, then ensure
that your application has permission
to access the key:
Open Windows Explorer.
Navigate to the C:\Documents and Settings\All Users\Application
Data\Microsoft\Crypto\RSA\MachineKeys
folder.
Select the files containing the keys that the WSE will need to
retrieve.
From the File menu, select Properties.
On the Security tab, add the ASPNET account and select th e Full
Control option.
Notes:
1. Determining which key file in the MachineKeys folder is
associated with a certificate can be
difficult. One easy method is to note
the creation date and time when
creating a new certificate. When you
view the files in the MachineKeys
directory, check the Date Modified
field for the corresponding date and
time.
2. If you have configured your system to run under a different
account than ASPNET, use that account
when granting permissions to access
the certificate.
As per my experience it could be failing because of two reasons.
Check if your cert has private key available.
If that is .net application then check if you have given permission to cert to make sure your application has permission to access the cert. In my case adding the "iis_iusrs" and given read permission does work for me.
Thanks.
After encountering the same exception: System.Security.Cryptography.CryptographicException, Object contains only the public half of a key pair, I proofed an alternative, but less optimal solution.
Situation: Certificate / key look up worked great inside of Visual Studio IIS Express, but while the Web Application was running under the proper IIS service, I always received the 'Contains only public half of key pair' exception.
I used the WSE3 CertificateTool to locate the private key section on the filesystem and attempted at length to adjust the user permission settings to give the ASP user permissions as per the above answer.
My eventual fix, which was not pretty, was to create a new IIS Application Pool specific to my Web service code and set the user Identity the pool runs as the Local machine owner of the certificate + private key.
The final location I installed the certificate in was "Local Computer / Trusted People".
Using WSE3 CustomPolicyAssertion, C# .NET:
clientToken = X509TokenProvider.CreateToken(StoreLocation.LocalMachine,
StoreName.TrustedPeople, "soap.partnersite.com", X509FindType.FindBySubjectName);
After updating the App Pool Identity, no private key file overrides were necessary when changing the application pool owner.