I'd like to automate the task of requesting client certificates from the CA attached to our Active Directory. Currently, I use certmgr and click "Request New Certificate" from the menu and do several other selections, including selecting an appropriate policy.
Surely, Powershell can help me with this, as I already use it to get rid of old certificates. Is there a module which can be used for this or does Powershell 3 cover this out-of-the-box?
I think certreq could be what you are looking for.
Certreq can be used to request certificates from a certification authority (CA), to retrieve a response to a previous request from a CA, to create a new request from an .inf file, to accept and install a response to a request, to construct a cross-certification or qualified subordination request from an existing CA certificate or request, and to sign a cross-certification or qualified subordination request.
Then there is another useful utility when dealing with certificates in windows - certutil
Related
I have a need to import my partners' X509 client certificates (along with complete chain) on all of my service fabric cluster nodes so that I can validate each incoming request and authenticate each partner based on the client certificate. This means when I import a client certificate, I want the related intermediate certificate (that signed the client certificate) and related root certificate (that signed the intermediate certificate) to be installed automatically into appropriate cert stores such as 'Intermediate Certificate Authorities' and 'Trusted Root Certification Authorities' in Local Machine store.
The reason why I want the entire chain stored in appropriate locations in certificate store is because I intend to validate incoming client certificate using X509Chain in System.Security.Cryptography.X509Certificates namespace in my service authentication pipeline component. The X509Chain seem to depend on the 'Trusted Root Certification Authorities' store for complete root certificate validation.
There is lot of information on how to secure a) node to node and b) managing client to cluster communication such as this: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security. However there is not much information on securing the communication between services (hosted in service fabric cluster) and the end user consumers using client certificates. If I missed this information, please let me know.
I don't have lot of partner client certificates to configure. The number of partners is well within manageable range. Also I can not recreate the cluster every time there is a new partner client certificate to add.
Do I need to do leverage
/ServiceManifest/CodePackage/SetupEntryPoint element in
SerivceManifest.xml file and write custom code to import partner
certificates (that are stored in the key vault or else where)? What are the pros
and cons of this approach?
Or is there any other easy way to import partner certificates that satisfies all of my requirements? If
so, please detailed steps on how to achieve this.
Update:
I tried the suggested method of adding client certificates as described in the above link under osProfile section. This seemed pretty straight forward.
To be able to do this, I first needed to push the related certificates (as secrets) in to the associated key vault as described at this link. In this article, it describes (in section "Formatting certificates for Azure resource provider use") how to format the certificate information into a Json format before storing it as secret in key vault. This json has following format for uploading pfx file bytes:
{
"dataType": "pfx",
"data": "base64-encoded-cert-bytes-go-here",
"password": "pfx-password"
}
However since I am dealing with public portion of client certificates, I am not dealing with pfx files but only base64 cer files in windows (which apparently are same as pem files elsewhere). And there is no password for public portion of certificates. So I changed the Json format to following:
{
"dataType": "pem",
"data": "base64-encoded-cert-bytes-go-here"
}
When I invoked New-AzureRmResourceGroupDeployment with related ARM template with appropriate changes under osProfile section, I am getting following error:
New-AzureRmResourceGroupDeployment : 11:08:11 PM - Resource Microsoft.Compute/virtualMachineScaleSets 'nt1vm' failed with message '{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "CertificateImproperlyFormatted",
"message": "The secret's JSON representation retrieved from
https://xxxx.vault.azure.net/secrets/ClientCert/ba6855f9866644ccb4c436bb2b7675d3 has data type pem which is not
an accepted certificate type."
}
]
}
}'
I also tried using 'cer' data type as shown below:
{
"dataType": "cer",
"data": "base64-encoded-cert-bytes-go-here"
}
It also resulted in the same error.
What am I doing wrong?
I'd consider importing a certificate on all nodes as described here. (Step 5) You can add multiple certificates in specified stores by using ARM templates, that reference Azure Key Vault. Use durability level Silver/Gold, to keep the cluster running during re-deployment.
Be careful with adding certificates in the trusted store.
If a certificate is created by a trusted CA, there's no direct need to put
anything in the trusted root authorities store (as they are already there).
Validate client certificates using X509Certificate2.Verify, unless every client has his own service instance to communicate with.
We have Windows Server 2012 R2 with installed Certification Authority role.
There we have certificate templates.
I want to get certificate from this server of specific template into specific container automatically by autoenrollment.
Now I automatically get certificate into personal store by group policy and autoenrollment.
But I want to get certificate into the specific store (for example, custom SCCM or SMS) automatically by autoenrollment.
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.
Amazon recently release Echo Alexa toolkit.
I received, registered my app. Alexa clearly recognizes my app exists. However it gives this error
Request Identifier:
amzn1.echo-api.request.d969c196-8b3e-4169-99c8-20f566889760 The
certificate does not have a path to a trusted authority. This happens
if you are using a self signed certificate. Voice feedback Echo heard:
"alexa start myapp"
I verified my COMODO CA (COMODO RSA Certification Auth) is on the list of authorized CA. I ensured my certificate bundle was valid.
Is there anything specific I need to ensure my bundle.crt is in the correct order for Alexa? (there is no mention that .com is required, I am using .net)
these my COMODO filenames.
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
mydomain-net.crt
ssl-bundle.crt
stn.private.key
Excited to get this to work ... please help
SA
I am now able to communicate with Alexa without issues. the source of the problem was the order of the certs and the incorrect directives in SSL and HTTP config files for apache.
I used
openssl s_client -connect 192.237.1.1:443
to verify that the certificate
Verify return code: 0 (ok)
Initially I was able to confirm the error by code and searched and fixed it.
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