Cloudvault client cannot establish connection due to certificate problems - certificate

I'm getting CloudVaultCertificateException with message Certificate found, but cannot access private key when trying to upload files.
Here is the stacktrace
Unhandled Exception: Microsoft.Infra.CloudVault.Library.Client.Exceptions.CloudVaultCertificateException: Certificate found, but cannot access private key.
at Microsoft.Infra.CloudVault.Library.Client.ExceptionHandler.LogAndThrowException(String message, TofuTagId tagId, Exception ex, Boolean isRetryable) in C:\rd\EngSys\DevServices\CloudVault\src\Library\Client\Exceptions\ExceptionHandler.cs
at Microsoft.Infra.CloudVault.Library.Client.PartitionUploader.Upload() in C:\rd\EngSys\DevServices\CloudVault\src\Library\Client\Upload\PartitionUploader.cs
at Microsoft.Infra.CloudVault.Library.Client.Uploader.PartitionedUpload(String targetDir, String fileFilter, String tempDir, String vaultType, Dictionary`2 metadata, String waitSignalPath, Boolean useFastIndexing, String[] watchExcludedPaths, SearchOption directoryRecursion, List`1 certificates, String configDirectory, Boolean useSymbolicLinks) in C:\rd\EngSys\DevServices\CloudVault\src\Library\Client\Upload\Uploader.cs
at Microsoft.Infra.CloudVault.Library.Client.CloudVaultManager.PartitionedUpload(String targetDir, String fileFilter, String tempDir, String vaultType, Dictionary`2 metadata, String configDirectory, String waitSignalPath, Boolean disableSymbolicLinks) in C:\rd\EngSys\DevServices\CloudVault\src\Library\Client\CloudVaultManager.cs
at Microsoft.Infra.CloudVault.Library.CommandLine.EntryPoint.Execute() in C:\rd\EngSys\DevServices\CloudVault\src\Library\CommandLine\EntryPoint.cs
Whats wrong with the cert and what do I need to do to make it work?

CloudVault client uses certificate to establish connection with service, that's why certificate must be properly installed on your local machine.
Here are steps to properly install certificate.
First of all you need to import cert in *.pfx format, not *.cer and enter password for private key during importing.
You need to choose Local Machine as a store location for cert
Cert must be installed into Personal store, which will be used by default if you leave Automatic store selection
And the last important thing which actually causes that exception is CloudVault client must have access to cert's private key
You can fix this either by running CloudVault client with admin rights or manually adding right to the private key. I recommend second way.
You need to run mmc from Run, File->Add/Remove Snap-in, double click Certificates and choose Computer account->Local computer.
Open Personal Certificates, find cert, right click on it and select All Tasks->Manage Private Keys and add Permissions to user that is used to run CloudVault client.

Related

ClickOnce VSTO solution signed with mage.exe - certificate not trusted error

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.

Keystore was tampered with, or password was incorrect

I am not able to Sign in to the application as it is throwing the following exception:
com.ibm.wsspi.channel.framework.exception.ChannelException: java.io.IOException: Keystore was tampered with, or password was incorrect
at com.ibm.ws.webservices.engine.xmlsoap.builders.WebServicesFaultProcessor.createFault(WebServicesFaultProcessor.java:415)
at com.ibm.ws.webservices.engine.xmlsoap.SOAPFault.getFault(SOAPFault.java:486)
at com.ibm.ws.webservices.engine.SOAPPart.getFault(SOAPPart.java:1090)
at com.ibm.ws.webservices.engine.SOAPPart.getFault(SOAPPart.java:747)
at com.ibm.ws.webservices.engine.Message.getFault(Message.java:883)
at com.ibm.ws.webservices.engine.Message.ifFaultThrowSelf(Message.java:863)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:279)
......
How to solve this issue?
Copy the newly added Cert data to a file and save it as “rsa.cert” or get the cert and name it as "rsa.cert"
Then open “ikeman.bat”
Open Key file(jks format) and then look for that certificate which you want to update (may be expired or near to expiry date or changed cert). Save the name of the cert which you want to change (for example these are the names of the certificates). Then click on that Cert and press the Delete button. Then Click on Add button and open the “rsa.cert” file which you save previously. Then give the name same as the name of the cert which you deleted.
Repeat the same process for the Trust File(jks format)
Restart the app server and run the application

Trouble installing certificate from .pfx file

I am trying to install a certificate on my local machine (Win Server 2003) with the X509Certificate2 class in a C# test console application. When I install the certificate with the following code, everything is fine:
var serviceRuntimeMachineCertificateStore = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
serviceRuntimeMachineCertificateStore.Open(OpenFlags.ReadWrite);
cert = new X509Certificate2(certificatePath);
serviceRuntimeMachineCertificateStore.Add(cert);
serviceRuntimeMachineCertificateStore.Close();
Problem is, that the private key of the certificate is not persisted, when installed without the X509KeyStorageFlags.PersistKeySet. So I tried to instanciate the certificate like this (the private key has no password, so I pass in an empty string):
var serviceRuntimeMachineCertificateStore = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
serviceRuntimeMachineCertificateStore.Open(OpenFlags.ReadWrite);
cert = new X509Certificate2(certificatePath, "", X509KeyStorageFlags.PersistKeySet);
serviceRuntimeMachineCertificateStore.Add(cert);
serviceRuntimeMachineCertificateStore.Close();
But trying to instanciate the certificate throws a System.Security.Cryptography.CryptographicException "Failed to load certificate: The specified network password is not correct.", even though the private key has no password.
If I import the certificate in the Microsoft Management Console without specifying a password it works great.
Does anybody know how to do this programmatically?
If you try to create an instance of X509Certificate2 with an empty password on Windows XP or Windows 2003, the "Failed to load certificate: The specified network password is not correct." exception will be thrown.
If you can, try to create a certificate with a password which is not empty. Then everything should be fine.
Hopefully this will help somebody (and to expand on uGeeen's answer:
User "S C" points out the following requirement for certificate passwords on Windows XP and Windows Server 2003.
0 < password.Length < 32
I have seen conflicting reports on whether 32 is allowed. I can confirm that I was using a 32 character password (an MD5 hash), and truncating it to 30 characters fixed the issue.
are you doing it from worker process or some other impersonated process? it may be just that the identity your process uses is initialized WITHOUT loading the identity user's profile, what seems to result with no access to the user's cerificate store.
i've had similar problem when loading a x509 cert with private keys from within ASP.Net/IIS proces, and turning on profile-loading for worker processed did the trick
In case anybody has a similar problem: I managed to install the certificate and persist the private key in another fashion. I found the WinHttpCertCfg command line tool that you can get from here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winhttp/http/winhttpcertcfg_exe__a_certificate_configuration_tool.asp
I then call this command line tool programmatically to install the certificate. This site gave me a hint on how to use it: weblogs.asp.net/hernandl/archive/2005/02/09/…
Cheers, Chris

Not able to import private key in certificate store on Windows7 desktop

I used the following code to import certificate WITH the password/private key in WinXp desktop.
Recently I migrated to windows7 and now I am not able to import the private key, although the certificate gets imported in the store.
What could be wrong here ? Any help is deeply appreciated.
X509Store store = new X509Store(StoreName.My);
X509Certificate2 certificate = new X509Certificate2("certFileName", "password" ); store.Open(OpenFlags.ReadWrite); store.Add(certificate); store.Close()
Noticed that even if I type in the wrong password, the certificate still gets imported and private key field shows null, obviously. But with correct password it should get populated :-(
Check if you have correct permissions :
How to set read permission on the private key file of X.509 certificate from .NET
You can also try adding storage flags to the certificate constructor:
X509Certificate2 certificate = new X509Certificate2("certFileName", "password", X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.MachineKeySet);
Setting this permmission might help:
https://serverfault.com/questions/48124/disabling-strong-private-key-encryption-on-a-personal-certificate

Object contains only the public half of a key pair

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.