I have a strange problem when importing a certificate from Azure Key vault to be used in an App Service. As you can see in the images below, it says the certificate is imported successfully but it does not show up as expected.
This have previous worked just fine for other app services and my custom domain matches the wildcard certificate that I am trying to use.
Any ideas what causes this strange behavior?
If you choose to upload or import a private certificate to App Service, your certificate must meet the following requirements:
Exported as a password-protected PFX file, encrypted using triple DES.
Contains private key at least 2048 bits long
Contains all intermediate certificates in the certificate chain
Some certificate authorities provide certificates in different formats, therefore before importing the certificate, make sure that they are either in .pem or .pfx format.
When you are importing the certificate, you need to ensure that the
key is included in the file itself. If you have the private key
separately in a different format, you would need to combine the key
with the certificate.
you can also refer https://www.huuhka.net/app-service-imported-ssl-certificate-from-another-subscription-kv/ if you have any failure messages while importing the key vault certificate
If you are using free managed certificate , you may check its pre-requisites to be fulfilled as free certificates come with few limitations , which can be referred from https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate?WT.mc_id=AZ-MVP-5003781#private-certificate-requirements
So, I made a workaround solution by setting an Managed Identity on my App Service giving it correct permissions to the keyvault. And then adding the application and correct permissions in Access policies for the keyvault.
After that the certificate showed up as expected when adding a binding on my App Service.
Seems you got the right solutions and might have encountered this issue due to your logged in user RBAC role.
When ever you use app service certificate it gets stored inside Azure Key vault and to use that key vault certificate/secret you need to have access policies to get the secret and set the secret.
More details at:
https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal#:~:text=Assign%20an%20access%20policy%201%20In%20the%20Azure,the%20Principal%20selection%20pane.%20...%20More%20items...%20
Related
When using Azure API Management Gateway its possible to implement client certification authentication to secure access to APIs. You can validate incoming request certs using policy expressions such as thumb checks etc.
When using client cert authentication method, what's the recommended process for certificate generation/management?
Cert responsibility?
Should I/gateway owner be generating the .pfx file (either self signed or by trusted CA), importing it to the gateway service and providing external clients with the .cer to install locally and auth with?
Should I/gateway owner be generating the .pfx file (either self signed or by trusted CA), importing the .pfx to the API Management gateway service (normally I'd imagine importing the .cer on a server/gateway but doesn't seem possible in Azure) and providing external clients with the .pfx to install locally and auth with?
Should the external client be responsible for generating their public/private key pair in their Org, signing it with a CA, installing it locally and providing me/gateway owner with a .cer file to import to the gateway (as above, not sure its possible to import .cer, I read only .pfx accepted in import process) or provide thumb for me to store/validate in policy?
Does anyone have any advice whether to issue clients requiring access to the same API the same (shared) cert or generate a new cert per client? They would all be using the cert to access the same API (+ additional auth methods, cert is just an extra step).
I've ready online tutorials describing all above bullets and where client-specific or single cert-per-API have been implemented so a little confused which is recommended approach?
The easiest way would be to have a single issuing CA certificate, you'd only need to upload its public key to APIM as that is all that's needed for APIM to validate incoming certificate. Then you'll be responsible to generate client certificates and distribute them to clients. In APIM you can setup a policy that would require certificate, check its issuer and validate, that should be enough to ensure that certificate is valid and issued by you.
Relying on self-signed certificates will be a hassle as you'd have to somehow let APIM know of each new certificate, having common issuing CA frees you of that worry.
Same goes for allowing remote clients to generate certificate - they would have to let you know of certificate and you'd need to list it in APIM one way or another.
You're free to decide how exactly to distribute certificates, a few things to consider:
Likely certificate will be your main way to tell clients apart. If that is important you may want to have different clients have different certificates.
If you want to deny access to a particular client you'll "revoke" that certificate, you need to make sure that other legitimate clients won't be affected.
I am trying to read Azure Configuration values and I also followed the answer provided in
Read configuration settings from azure cloud service with .NET C#
I want to know from where I can get the following parameter values:
subscriptionId
thumbprint
StoreLocation.CurrentUser
StoreLocation.LocalMachine
X509Store store = new X509Store("My", location) -- what i need to write at the place of "My"
-- what i need to write at the place of "My"
You also need to use My. For more information please refer to What are the Windows system certificate stores?
Each of the three stores contain a number of folders which certificates go into
Personal (can be known as My when using scripts to add certs)
Trusted Root Certification Authority (can be known as Root)
Enterprise Trust
Intermediate Certification Authority
Active Directory User Object
Trusted Publishers
Untrusted Certificates
Third Party Root Certification Authorities
Trusted People
We could get the subscriptionId from Azure portal, details please refer to this document.
About thumbprint please refer to How to: Retrieve the Thumbprint of a Certificate
StoreLocation.CurrentUser and StoreLocation.LocalMachine is StoreLocation Enum
I am learning about Azure Key Vault, and one of the scenarios it supports is certificate authentication, which you can read about here.
The samples do a great job of explaining how to make a self-signed certificate for local testing, which I have gotten to work without an issue. My question now is, how do I go about making a certificate for production deployments? Do I purchase this from a service somewhere? If so, what type of certificate do I need, exactly?
Unfortunately, there is no documentation anywhere that I could find in Azure Key Vault that outlines how to make (or what is expected/assumed) in a production-level certificate.
I basically have a few requirements/expectations based on my research/investigation so far:
I would like to use a trusted, external service (CA?) to purchase the certificate from.
The cheaper the certificate the better. :)
I would like to be able to create a certificate with custom data extensions.
In addition to my requirements, I have a specific question in regards to the certificate: What type of certificate do I need? Is this a server authentication certificate? Or a client authentication certificate? Or... ?
I have spent the past hour going through several SSL certificate providers, but none of them really could give me a great answer for the type of certificate I am looking for (when I provided the link to Azure certificate above to them). So, I decided to do what I should have done in the first place, and put my question up here to the esteemed community. :)
Thanks in advance for any assistance.
If you want the cert for SSL you want to get a Server Authentication certificate (it proves that the server, ie your site, is who it claims to be).
You can buy it from any trusted service and upload it to Azure Key Vault. Just google "buy ssl certificate". I think you can get one for as little as $30 if I remember correctly.
You can use Key Vault to enroll for certificate from public CAs such as DigiCert and GlobalSign. Look at the "Enroll programmatically from Public CA" section in https://blogs.technet.microsoft.com/kv/2016/09/26/get-started-with-azure-key-vault-certificates/
You can use the Key Vault REST API to programmatically enroll for certificates -https://learn.microsoft.com/en-us/rest/api/keyvault/createcertificate
The certificate policy allows for some customization like specifying which KeyUsage and EKUs you want in your certificate.
I'm adding support for JWT tokens in my Web Application, and I have an X509 certificate which it needs for signing those tokens.
I have rejected the idea of using the same certificate we use for HTTPs (see Can I use the Private Key Certificate of Web App to sign JWT?).
I think a self signed certificate should do the trick, in fact I can't see any advantages of a web of trust in this scenario (that doesn't mean there aren't any, I just can't think of any).
The web application runs on a farm of web servers. My current plan is to generate a self signed cert and put the X509 certificate into the certificate store in Windows on each machine. Our IT department are checking, but they think they can roll that out to all the Web Servers in the farm using Group Policy. So this seems like a feasible plan.
The certificate store in windows looks pretty confusing to me. I think there are two options:
1) Put it in "My" store for the user under which the IIS App pool run. There are many app pools, so potentially the certificate will be in many stores.
2) Put it under the LocalMachine store, and then grant explicit access to the specific certificate for the IIS user(s).
3) Something else I can't think of.
Is there a "correct" place for these type of certs, and if so where is it?
The usual CertificateStore for signing certificates is the My store. I normally place them in LocalMachine location, but it is probably safer to put them in the certificate store for the Application Pool identity itself.
I would then give the Application Pool read-only access to this certificate only (right click certificate, then 'All Tasks' > 'Manage Private Keys', then add your Application Pool identity and give 'Read' permissions only.
I am developing one asp.net website and I will be hosting the site on windows azure. My requirement is when user access the site like www.xyz.com\admin then live id authentication should happen but when the user access the site www.xyz.com then no need do authentication.
After referring to an MSDN document I come to know about ACS with WIF, so I created the namespace and did so on so on.
But whenever I am accessing the federation URL (https://xyz.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml) I am getting error:
ID:1089 unable to connect the remote server.
I unfortunately deleted the certificate and keys and service identities in windows azure I don't know how to get it back, also I don't how do fulfill my requirement.
If you deleted the certificates and keys they all you need is to just create new one(s). You can either use Self Signed certificates, or use X.509 certificates issued by a trusted Certificate Authority. Once you get your X.509 certificate (it shall include a private key) you can upload it in the ACS management portal (which is locate at https://xyz.accesscontrol.windows.net/):
The FederationMedatadata.xml cannot be generated without the Token Signing certificate.
Or, the easiest for you, would be to just delete that namespace and create a new one.