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.
Related
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
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 having problems correctly installing the OAuth certificate required for Xero partner integration on IIS 7.5 on Windows Server 2008 R2. There used to be guidance from Xero on this at http://developer.xero.com/documentation/advanced-docs/using-partner-applications-with-iis/ but the page just 404s now.
I've installed the certificate to the Trusted Root Certifications Store as per the prior Xero advice, and my code can retrieve the certificate (using its serial number); but when I try to access the private key, I get a CryptographicException: Keyset does not exist error, which other SO posts suggest is a permissions error (my application runs under a dedicated service account), but all those posts assume the certificate is installed in the personal certificate store - the TRC store does not give me the option of granting permissions to the service accounts or any other account.
I think that page used to give information about installing an Entrust client certificate as partner applications in the past needed to use one.
You don't need to use a client certificate these days and partners should instead direct their traffic to "https://api.xero.com" instead of "https://api-partner.network.xero.com".
You also don't need to install your oAuth certificate as that certificate is used only for signing your requests.
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.
We have a backend server that services a multi-platform app that will be launched on iOS, Windows 8, Windows Phone 8 and Android. We'd like to use in production as few certificates as possible (preferably just one) to attain the following purposes:
secure communication (HTTPS) with the client application
authentication to the Windows Phone Push Notifications Service
authentication to the Apple Push Notifications Service
Besides taking care that the certificate is issued by a common trusted root authority, are there any other impediments that could prevent a single certificate from being used simultaneously for all these? Is it a viable possibility or is it instead necessary to resort to one certificate for each of the above purposes?
Gabriel I guess there is a problem. Main one is that HTTPS certificate private key cannot be coded by a secret this kind of certificate contain *.crt and *.key file which are not secured. When You want authenticate yourself or server in some Service for example Windows phone push like you have listed there is need to create hash for your private key with secret aka pin or password. What make You use at least two different certificates.
Second thing is that purpose of using certificates is to validate the issuer and to authenticate user/service provider. HTTPS ssl certificate issued by a trusted CA show to the user Hey this is trusted website You should not be afraid passing sensitive data through the service, and the certificates which are used to authenticate are just saying Hey its me I am authorized to use this application Purpose of those certificates and different so certificates them self should be different. Using the same cert for actions like You have listed cause necessaries vulnerabilities and is highly NOT RECOMMENDED