I am trying to use Postman Chrome app to make REST calls against Microsoft Azure Service Management API. However, I get the following error
<Message>The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.</Message>
Here is what I did.
I created a self signed certificate. I uploaded that certificate to Azure Certificate store in the management portal and added the same to the trusted root certification authorities in my windows certificate store. However, I can't still make a valid API call. Can someone guide me down the right path here.
Finally I solved it myself. Here are the steps
1) Create a certificate using the following command in your Visual Studio Command Prompt
makecert -sky exchange -r -n "CN=<certname>" -pe -a sha1 -len 2048 -ss My <certname>.cer"
2) Upload the cer file in the settings portion of the azure management portal
3) Export a pfx file containing the private key to a location on your machine.
4) Add that pfx file to Chrome in settings certificates in trusted root certificates list
5) Make the REST call using Postman.
Enhancement of #csprabala's answer as my edit of his answer was rejected. Credits go to #csprabala.
Create a certificate using the program makecert. You find it either in your Visual Studio command window or in another location. Run this command:
makecert -sky exchange -r -n "CN=<certname>" -pe -a sha512 -len 2048 - sv "<certname>.pvk" "<certname>.cer"
Upload the <certname>.cer file in the settings portion of the Azure management portal .
Create a <certname>.pfx file containing the private key with this command (program is in the same location as in 1.):
pvk2pfx.exe -pvk "<certname>.pvk" -spc "<certname>.cer" -pfx "<certname>. pfx"
Import the file <certname>.pfx to the Windows user certificates store. You can do this in Chrome in the settings under "HTTPS/SSL" > "Manage Certificates ...". The "Personal" certificate store is appropriate.
Make the REST call using Postman.
Related
I use the below script to import a certificate in a pipeline build process,
Powershell script:
param($PfxFilePath, $Password)
$absolutePfxFilePath = Resolve-Path -Path $PfxFilePath
Write-Output "Importing store certificate '$absolutePfxFilePath'..."
Add-Type -AssemblyName System.Security
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
$cert.Import($absolutePfxFilePath, $Password, [System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]"PersistKeySet")
$store = new-object system.security.cryptography.X509Certificates.X509Store -argumentlist "MY", CurrentUser
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::"ReadWrite")
$store.Add($cert)
$store.Close()
Get below error:
. 'C:\JobAppAgent_work\1\s\JobApp\DevOps\Build\Import-PfxCertificate.ps1' -PfxFilePath $env:DOWNLOADSECUREFILE1_SECUREFILEPATH -Password ****
Importing store certificate 'C:\JobAppAgent_work_temp\DD.Job.Desktop_TemporaryKey.pfx'...
##[error]Exception calling "Import" with "3" argument(s): "The specified network password is not correct.
This script was running fine when build was running on Azrure PipeLines. Now I create a private Agent pool that runs on a Window 10 VM.
Make sure that the certificate is valid and has not expired. You can check the expiration date of the certificate by double-clicking on it and viewing the details.
Check that the certificate is properly installed on the machine where the build is being performed. If the certificate is not installed, it will not be available for use in the build process.
Make sure that the certificate is correctly referenced in the build pipeline. This may involve specifying the path to the certificate file or the thumbprint of the certificate.
If you are using a self-signed certificate, make sure that it is trusted by the machine where the build is being performed. To do this, you will need to install the certificate in the trusted root certification authorities store on the machine.
If you are using a certificate from a certificate authority (CA), make sure that the CA is trusted by the machine where the build is being performed. This may involve installing the root certificate of the CA on the machine.
This is a PowerShell script that imports a certificate from a file with a given password into the "MY" store in the current user's certificate store. The certificate is imported using the Import method of the X509Certificate2 class, which takes as input the path to the certificate file, the password, and a set of key storage flags. The script then creates an X509Store object representing the "MY" store in the current user's certificate store, opens the store in read-write mode, adds the imported certificate to the store, and closes the store.
This script assumes that the certificate file is in the Personal Information Exchange (PFX) format, which is a common format for storing certificates and their private keys. PFX files are often used to export or import certificates, and they can be password-protected for added security.
Verify that the password you are using to import the certificate is correct. It's possible that the password has been changed or entered incorrectly.
Check that the certificate file has not been damaged or modified in any way. If the file has been altered, it may be causing the import to fail.
Make sure that the certificate file is accessible to the machine where the script is being run. If the file is on a network share or another machine, check that the machine has the necessary permissions to read the file.
If the certificate file is password-protected, make sure that the password has not expired or been revoked.
Try running the script with different key storage flags to see if that has any effect on the error. For example, you could try using "Exportable" instead of "PersistKeySet" as the key storage flag.
I had Configure the Domino Credential Store.
I had modified the Domino Proton Server settings that enable client authentication.
I created the Vault ID.
I created the IAM-store.nsf from template with error message.
Error executing agent 'DeleteExpiredDocs' in 'iam-store.nsf'. Agent signer 'Domino Template Development/Domino': You are not authorized to perform that operation
I gave the IAM's functional ID access to the database.
I installed the IAM services for domino with the following message.
result screen of install domino-iam-service-2.2.0.tgz
Since I would like to config the iam-services for my testing server.
I select to setup the pilot mode.
According to the tutorial, https://doc.cwpcollaboration.com/appdevpack/docs/en/iam_landing_page.html
I could access the demo database, with anonymous setting of proton server.
C:\src\domino-db\package>npm run ptest -- read serv.org.com:3003/App\node-demo.nsf -q "Form = 'Contact' and LastName = 'Moody'"
read the content of demo database
Config the pilot mode successfully.
What is doing wrong?
Error, when try to startup pilot mode of IAM Service
I have put all the certificates to the folder config/certs,
in which the certificates are created by create_certs.cmd from the tutorial.
And I have convert the ca.crt into ca.pem.
Besides, I also put the keys created by ProtonCA into the config/certs.
Keys created by ProtonMicroCA
According to the tutorial, I modified the make_certs.cmd as the following:
make_certs.cmd
the certificates are posted to the config/certs directory
I'm not sure about your complete setup, a support ticket would help us diagnose this better. There should be a ca folder in the config/certs directory that contains any root certs you're using (like the ca.pem you have)
I have installed SSL successful in my azure server but it's not binding with domain. I am getting following error message.
It is not clear on what certificate you are using. To use a certificate in App Service, the certificate must meet all the following requirements:
Signed by a trusted certificate authority
Exported as a password-protected PFX file
Contains private key at least 2048 bits long
Contains all intermediate certificates in the certificate chain
As highlighted by Snobu you may regenerate the certificate (for Self-Signed) with: extendedKeyUsage = critical,codeSigning,1.3.6.1.5.5.7.3.1 in the x509_extensions in the file. Refer this document for the step-step instructions on uploading a certificate.
I am trying to implement client certificate authentication on IIS 8. I have deployed my configuration on a development machine and verified it working as expected there. However after setting up on the server, whenever I navigate to the site and am prompted for the client cert, I select it and immediately get the 403.16 error. The failed requests log gives the error code 2148204809 and message "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider."
I have a valid client cert and also a valid CA cert. The CA cert is installed in Trusted Root Authorities on the computer account on both the server and the client machine, and the client cert is installed in the Personal area of the Current User account on the client machine.
The client cert is signed directly by the root CA and as I said, both are valid. There are no other certs in the chain and there are no intermediate certs in the Trusted Root Authorities area.
The IIS configuration has sslFlags = SslNegotiateCert and iisClientCertificateMappingAuthentication is enabled.
The server is not configured to send a CTL and we have SendTrustedIssuerList = 0.
I cannot see why the client cert should not be trusted.
Windows 2012 introduced stricter certificate store validations. According to KB 2795828: Lync Server 2013 Front-End service cannot start in Windows Server 2012, the Trusted Root Certification Authorities (i.e. Root) store can only have certificates that are self-signed. If that store contains non-self-signed certificates, client certificate authentication under IIS returns with a 403.16 error code.
To solve the problem, you have to remove all non-self-signed certificates from the root store. This PowerShell command will identify non-self-signed certificates:
Get-Childitem cert:\LocalMachine\root -Recurse |
Where-Object {$_.Issuer -ne $_.Subject}
In my situation, we moved these non-self-signed certificates into the Intermediate Certification Authorities (i.e. CA) store:
Get-Childitem cert:\LocalMachine\root -Recurse |
Where-Object {$_.Issuer -ne $_.Subject} |
Move-Item -Destination Cert:\LocalMachine\CA
According to KB 2801679: SSL/TLS communication problems after you install KB 931125, you might also have too many trusted certificates.
[T]he maximum size of the trusted certificate authorities list that the Schannel security package supports is 16 kilobytes (KB). Having a large amount of Third-party Root Certication Authorities will go over the 16k limit, and you will experience TLS/SSL communication problems.
The solution in this situation is to remove any certification authority certificates you don't trust, or to stop sending the list of trusted certifiation authorities by setting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\#SendTrustedIssuerList registry entry to 0 (the default, if not present, is 1).
If the issue continues to persist after the above steps, restart the machine.
In my case I'd been adding the root cert into the 'current user' certificate store on the server and was getting the 403.16 error.
Adding my root cert to the Trusted Root Authorities store for the local machine resolved the issue.
Follow the steps below on the server running IIS.
For Windows Server 2008 R2:
Right click on the certificate file and select 'Install Certificate'. Click next.
Select 'Place all certificates in the following store' and click 'Browse...'
Check 'Show physical stores'
Expand 'Trusted Root Certification Authorities' and select 'Local Computer'. Click OK.
Click Next/Click Finish.
For Windows Server 2012 R2:
Right click on the certificate file and select 'Install
Certificate'.
Select 'Local Machine'. Click Next.
Select 'Place all certificates in the following store' and click 'Browse...'
Select 'Trusted Root Certification Authorities'. Click OK.
Click Next/Click Finish.
For Windows 7:
Start -> Run -> mmc.exe
File -> 'Add or Remove Snap-ins'. Select 'Certificates', click 'Add >' and select 'Computer account' and then 'Local computer'. Click Finish/OK
Expand Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates. Right click on Certificates and select All Tasks -> Import.
Select the certificate file and click next.
Select 'Place all certificates in the following store' and click 'Browse...'
Check 'Show physical stores'
Expand 'Trusted Root Certification Authorities' and select 'Local Computer'. Click OK.
Click Next/Click Finish.
I got this error in IIS Express:
HTTP Error 403.16 - Forbidden
Your client certificate is either not trusted or is invalid.
Looking at the TraceLogFiles I saw the following error:
<RenderingInfo Culture="en-US">
<Opcode>MODULE_SET_RESPONSE_ERROR_STATUS</Opcode>
<Keywords>
<Keyword>RequestNotifications</Keyword>
</Keywords>
<freb:Description Data="Notification">BEGIN_REQUEST</freb:Description>
<freb:Description Data="ErrorCode">A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
(0x800b0109)</freb:Description>
</RenderingInfo>
Turned out when I installed Razer Synapse the installation also put a certificate for chromasdk.io in Trusted Root Certification Authorities under Computer Account -> Local computer. I removed this and then everything worked.
Just sharing my experience with Windows 2019 server and IISExpress in combination with a self-signed certificate. I couldn't get it working with editing the registry and in the end I didn't need to.
The following three steps got me there:
Generate a root certificate for the localmachine cert store with powershell:
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=TestRootCert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\LocalMachine\My" -KeyUsageProperty Sign -KeyUsage CertSign
Generate a client certificate for the localuser cert store, based on the root cert with powershell:
New-SelfSignedCertificate -Type Custom -Subject "CN=TestChildCert" -Signer $cert -TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.2","2.5.29.17={text}upn=test#local") -KeyUsage DigitalSignature -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
Move the root cert from Personal\Certificates to Trusted Root Certification\Certificates
After this I could select the TestChildCert and it was accepted just fine.
I am trying to setup a website (local testing atm), to connect to azure rest api to see our settings. I created a cert locally (W7 machine):
makecert -sky exchange -r -n "CN=azureConnectionNew" -pe -a sha1 -len 2048 -ss My "azureConnectionNew.cer"
I can see the cert in the certs MMC snap in. (do not have a right click edit permissions option when I view the cert in here).
I have a class library that setups up the connection, the cert is passed in by getting the cert (via the thumb string), this works great for the console app, but when I try and do this in a web app it all goes wrong. I get 403 errors.
I first thought that this was due to the fact that the website is running as the ApplicationPoolIdentity so doesn't have access to the cert. So I tried passing in the cert (to the same code as the console app), by loading the actual file:
var path = #"C:\temp\azureconnection\azureConnectionNew.cer";
var cert = new X509Certificate2();
cert.Import(path);
I still get 403 errors.
I tried exporting the cer file from MMC certificates snap in as a pfx file, (with private keys included). I set the local IIS set to use this cert and navigated to the https version of my local site but still got 403.
I am not sure how to include / setup / reference the cert so that IIS can send a HttpWebRequest from the server side to Azure and get a valid response.
It is always better to use Thumbprint of the certificate to get the certificate. Please make sure you have created the certificate correctly. Also please check you have placed the certificate in Personal certificate section in Local Machine. You can check this using MMC snap in. please try below code..
var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
var certificate = store.Certificates
.Cast<X509Certificate2>()
.SingleOrDefault(c => string.Equals(c.Thumbprint, “CertificateThumbprint”, StringComparison.OrdinalIgnoreCase)); // please replace CertificateThumbprint with original Thumbprint
This isn't the right way to use the certificate - it needs to be stored in the personal/certificates store of the user running the code (you should update the App Pool identity to be a user who can login and into whose certificates you import the cert. Here's sample code showing you how to use the service API: http://code.msdn.microsoft.com/windowsazure/CSAzureManagementAPI-609fc31a/