My goal is to use a powershell script to get an instance of an azure service with Get-HostedService.
As a preparation, I created a self-signed certificate and uploaded as a Management Certificate via the Azure Management portal, according to http://msdn.microsoft.com/en-us/library/gg551722.aspx.
After that, I
See my certificate and its thumbprint in PS cert:\CurrentUser\My
The thumbprint matches the thumbprint I can see in manage.windowsazure.com > settings > management certificates
My test script just tries to create a $service instance and goes like this:
Add-PSSnapin WAPPSCmdlets
$cert = Get-Item cert:\CurrentUser\My\<thumbprint of certificate>
$service = Get-HostedService <my service name> -Certificate $cert -SubscriptionId <my subscription id>
The 3rd line (Get-HostedService command) results into:
Get-HostedService : HTTP Status Code: ForbiddenError - HTTP Error Message: The server failed to authenticate the request. Verify that the certificate is valid and is associated with this subscription.
The machine (A) I am trying to do this on is behind a corporate firewall. According to our IT there is no event in the firewall log that may indicate a problem. The same script works on a different machine (B) that is behind another firewall (in a DMZ). However, both machines have access to the internet.
I tried to use the same certificate (exported from machine A and imported into machine B ) as well as to create a new certificate for the new machine A.
On both machines, double-cllcking on the certificate (in the mmc snap-in) shows:
This CA Rot certificate is not trusted. To enable trust, install certificate in the trusted Root Certification Authorities store
and
You have a private key that corresponds to this certificate
I tried to add the certificate to "Trusted Root CAs" but that did not help.
The certificate is
sha1 RSA 2048 bits
not expired
What can I do to solve the problem or get more debugging information?
Related
I am trying to setup some certificates for different hostnames (aliases) for SQL Server Reporting Services so that I can secure connections on my own machine for testing purposes. My understanding is that these certificates need to be signed by a trusted Root Certificate Authority (explained here). After doing some research, I've found a lot of helpful information that can generally be summarized by this post; the information I've found tells me how to create new certificates using Powershells New-SelfSignedCertificate cmdlet.
So now I know how to create a new Root CA, and I know how to create an SSL certificate for a given hostname which is signed by the new Root CA. However, I can't find anywhere that explains how to re-use an existing Root CA. I want the code to work like this:
$rootCA = <# What goes here? #>
$TestSigned = New-SelfSignedCertificate -subjectName "CN=TestSignedByRoot" -Signer $rootCA
Am I supposed to just create a new Root CA every time I want to create a certificate? That seems insane so I sure hope that's not the case. If any of you could provide some explanation and sample code it would be greatly appreciated.
To get a certificate from the certificate store with known hash:
$rootCa = ( Get-ChildItem -Path cert:\LocalMachine\My\EEDEF61D4FF6EDBAAD538BB08CCAADDC3EE28FF )
To see what certificates there are in the My store:
Get-ChildItem -Path cert:\LocalMachine\My
To get a certificate by subject name, use Where-Object to check the Subject property:
$rootCa = Get-ChildItem -Path cert:\LocalMachine\My | Where-Object {$_.Subject -eq "CN=My Awesome Root CA"}
You are missing a key word here: Trusted. Not just by you, but by any computer that tries to verify the validity of the certificate. Most companies will have a PKI solution to be able to issue certificates internally, and will have the certificate for the Root CA pushed out via GPO into the Trusted Roots folder of the local machine certificate store. The Root CA should be something that is already established, and trusted by the computers that will be connecting to your SQL server. I would recommend contacting your IT or Security department to ask about if the company has a Trusted Root CA that you can get your certificate signed by, or if they can issue you a certificate that chains to the trusted root.
Edit: Ok, I missed the point. My understanding was 'my machine' being the SQL server that you support vs other computers that would connect to it. If the only computer that you are concerned with is your own, then this comes down to:
Create a Certificate Signing Certificate (Certificate A)
Add Certificate A to the Trusted Root folder of your LocalMachine
certificate store
Create a self signed certificate (Certificate B)
using Certificate A as the signing certificate
Once you have completed steps 1 & 2 you can repeat step 3 as many times as needed to make additional certificates. You should only need 1 Root cert ever. The important part is that the Root certificate is trusted by the 'client', so that when it connects to the SQL reporting service and sees the certificate it can establish a chain of trust to the root certificate that initiated the chain.
To use an existing trusted certificate, you will need a copy of the trusted certificate in the Personal Certificates folder (cert:\LocalMachine\My) I used CertMgr. Else when you finally run your command to create the self signed certificate, you get an error
New-SelfSignedCertificate: CertEnroll::CSignerCertificate::Initialize: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
We have a root certificate authority made with OpenSSL. Its file-based, runs on RHEL, uses "serial" and "index.txt" etc.
Now in a lab environment we have added an intermediate standalone certificate authority using Active Directory Certificate Services, standalone (i.e. not an AD or domain member), running on Windows Server 2012 (all latest updates applied). We signed the intermediate CA with our root and ADCS is up and running successfully. But what we're finding is that we actually cannot issue any certs from this intermediate CA.
When we use the management console and attempt to issue a requested cert, the cert ends up in "Failed Requests" with the message:
Active Directory Certificate Services denied request 4 because The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614 CRYPT_E_NO_REVOCATION_CHECK).
The request was for CN=obelisk.sand.idfconnect.lan, OU=IDFC, O="IDF Connect, Inc.", L=Wilmington, S=Delaware, C=US. Additional information: Error Constructing or Publishing Certificate Resubmitted by OBELISK\Administrator
If I look at the request, I can see the is defined as:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk Intermediate CA.crl (file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk%20Intermediate%20CA.crl)
If I use IE to browse that file:// url, it pops open Windows Explorer, where I see the files I'd expect, i.e.
nsrev_Obelisk Intermediate CA.asp
Obelisk Intermediate CA.crl
Obelisk Intermediate CA+.crl
obelisk.sand.idfconnect.lan_Obelisk Intermediate CA.crt
Lastly, when I view the properties of the intermediate CA from the MMC, and look at its certificate, at the bottom of the details it says: "Extended Error Information: Revocation Status : The revocation function was unable to check revocation for the certificate."
Any advice to get this intermediate CA working greatly appreciated!
Add the public root certificate to the machine store (certlm.msc) trusted root certificate authorities.
Add the public root certificate CRL to the machine store (certlm.msc) trusted root certificate authorities.
I am stumped on this one. I have a secure cluster with some encrypted application settings. The app runs fine on my local cluster, but not when deployed to the cloud.
The application deploys ok, but fails to start up with the following error: Failed to ACL folders or certificates required by application. Error:FABRIC_E_CERTIFICATE_NOT_FOUND.
I have created a self signed cert, exported it (with the private key) to a PFX, and uploaded it to the vault:
New-SelfSignedCertificate -Type DocumentEncryptionCert -KeyUsage DataEncipherment -Subject mycert -Provider 'Microsoft Enhanced Cryptographic Provider v1.0'
Invoke-AddCertToKeyVault -SubscriptionId 'xxxxx-bxxxxfb9-xxxx-xxx-xxxxx' -ResourceGroupName 'vault-sec-studio-dev' -Location "Central US" -VaultName 'vault-sec-studio-dev' -CertificateName 'mycert' -Password "myPass" -UseExistingCertificate -ExistingPfxFilePath "C:\temp\Azure\Dev\mycert.pfx"
I add the certificate to the cluster security tab by referencing the thumbprint:
I update the ApplicationManifest.xml:
<Principals>
<Users>
<User Name="Service1" AccountType="NetworkService" />
</Users>
</Principals>
<Policies>
<SecurityAccessPolicies>
<SecurityAccessPolicy GrantRights="Read" PrincipalRef="Service1" ResourceRef="mycert" ResourceType="Certificate"/>
</SecurityAccessPolicies>
</Policies>
<Certificates>
<SecretsCertificate X509FindValue="72C57495F3034E072CA6F536EEABE984AA869CBC" X509StoreName="My" X509FindType="FindByThumbprint" Name="mycert" />
</Certificates>
The Sevice Fabric Explorer page shows the upgrade was installed but failed to start. Several nodes are in error status:
When remoting in to the VM's I don't see this cert installed. I see the main cert used to secure the cluster, but not this admin cert.
I have tried to manually install the cert on each VM, but getting the same result.
I have spent a ton of time on this, and can't seem to get anywhere, so I'm hopeful someone can give me some pointers here.
Update:
I'm seeing this in the event log on the VM. Talks about the private key which makes me think there is something wrong with the cert, or pfx?
Failed to get the Certificate's private key. Thumbprint:72C57495F3034E072CA6F536EEABE984AA869CBC. Error: FABRIC_E_CERTIFICATE_NOT_FOUND
This issue is now finally resolved. I can't say I completely understand this, but this is what I found:
Don't create the Service Fabric Cluster using the Portal. You'll need to use the template so you have access to configure the certs.
Also no need to mess around with Admin Certs on the security tab that I originally did (see original question). Those don't work for this, or at least not the way I'd expect them to.
You must edit the ARM template and add the following certificate information to the "secrets" array on each VM:
Note section above is added and points to a Certificate URL
"settingCertificateUrlValue": {
"value": "https://vault-my-site.vault.azure.net:443/secrets/studiosecrets/487a94749ee148979cc97a68abe9fd3a"
},
The cluster is now "green" and the app runs fine.
The following set-up is given:
We are a fairly small branch of a big enterprise sitting on the bottom of a complex WinServer 2012 R2 AD. Therefore we are somehow restricted in our policies.
Our development department has three PowerShell developers who want to use their scripts securely.
We implemented an AD CS to sign our scripts by our own root certificate authority.
The technical steps to implement our certificates are the following:
Create a private key with a public certificate using openssl.
Sign the certificate by our certificate authority.
Import the signed certificate into an AD users account along with the public certificate of the CA into the trusted CAs.
The certificate user "ScriptUser" is not an AD user, therefore we import his certificate into the trusted users area.
Signing and testing:
On the client system (Windows 7 or Windows 10) we tested to sign a
PowerShell script which went ok.
When running the script locally we get an error message that the certificate owner is not trustworthy. After committing the script runs.
We expected the script to run without any dialogue.
What's our fault?
My certificate is stored in a custom store under "Certificates(Local Computer)" instead of under "Personal".
Normally, if the cert is located under personal, i just use C:>netsh http add sslcert ipport:0.0.0.0: certhash= appid= certstorename=MY
where, certstorename=MY is already assumed by default if not specified.
This works fine until we were required to store the certificate in a custom store other than the existing personal, trusted people, trusted publishers, etc. etc.
If we called our new store "my cert store", how would the new netsh command look like?
how does the word "MY" map to the "Personal" store? is there a dictionary someplace that maps these?
i checked the System.Security.Cryptography.X509Certificates namespace and there exises an enum called StoreName with the following values:
AddressBook - The X.509 certificate store for other users.
AuthRoot - The X.509 certificate store for third-party certificate authorities (CAs).
CertificateAuthority - The X.509 certificate store for intermediate certificate authorities (CAs).
Disallowed - The X.509 certificate store for revoked certificates.
My - The X.509 certificate store for personal certificates.
Root - The X.509 certificate store for trusted root certificate authorities (CAs).
TrustedPeople - The X.509 certificate store for directly trusted people and resources.
TrustedPublisher - The X.509 certificate store for directly trusted publishers.
I tried all of them on the netsh command as certstorename and i always get this error:
SSL Certificate add failed, Error:1312
A specified logon session does not exist. It may already have been terminated.
What you are trying to do seems correct. Could you retry after applying hotfix http://support.microsoft.com/kb/981506 for a problem which actually matches your symptoms exactly.
A huge flaw is that even if the PrivateKey is not persisted properly, the private key icon will still show up in mmc and it will say "There is a private key associated with this certificate". To know for sure that the private key is being properly imported,
Right click on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and take a note of how many files are in the folder (this is where the private keys are kept).
Import the pfx file / however you are adding the certificate/key to the store
Check the file count again of that folder, there should be 1 more file than before
You can try testing this with a newly created, self-signed certificate with a tool like open-ssl. Was stuck on this for weeks until I found this stackoverflow post, Inserting Certificate (with privatekey) in Root, LocalMachine certificate store fails in .NET 4
Another gotcha is to be sure the certificate is in Local Computer (not user), but it looks like you already got that part down.
Open your certificate and double check whether it actually contains a PrivateKey. Depending on how you exported/imported it, it may have been truncated to a public-only data.
In explorer, just double click and check whether "this cert contains private key" warning label is visible on the first tab, just under the expiry dates
I had this problem when the certificate was installed in my local user store, instead of the local machine store. Installing in localMachine/my cleared it up.
Derrick. The certstorename just needs quotes. The AppId is the hardpart. Remove the EnhancedKeyUsageList part if you made a self-signed cert. Otherwise prefer to use a cert designed for a server side certificate.
$appid = "appid={"+(get-host).InstanceId.guid+"}"
$certhash = ls Cert:\LocalMachine\my | where {$_.EnhancedKeyUsageList -Match 'Server' -and $_.subject -match (hostname)}|select -expand Thumbprint -last 1
$cmdline='netsh http add sslcert ipport=0.0.0.0:443 certhash=' + $certhash + ' "' + $appid + '"'
resulting with netsh http add sslcert ipport=0.0.0.0:443 certhash=DD2AA37F947FC61766AF95ADA93DFDC1B171CB8B "appid={723b1673-7ec2-42f2-96c3-e1f5b726feaf}" certstorename="my cert store"
netsh http delete sslcert ipport=0.0.0.0:443
Invoke-Expression $cmdline
SSL Certificate successfully added