I have recently setup a WCF service against an STS using WIF, I am trying to understand the certificates needed and what they affect, I have a certificate against IIS allowing HTTPS communication but in the STS configuration there is a reference to two more certificates. e.g.
<appSettings>
<add key="SigningCertificateName" value="CN=STSTestCert"/>
<add key="EncryptingCertificateName" value="CN=DefaultApplicationCertificate"/>
</appSettings>
In the MSDN documentation(http://msdn.microsoft.com/en-us/library/ee748498.aspx) it states
The STS uses a default certificate to sign the tokens it issues. This cert is named “STSTestCert” and it is added to your certificate store automatically for use by the STS. The certificate file is present in the STS project. The password for the file is “STSTest”. This should not be used in a production exercise. You can replace the default certificate with any other certificate
My question is what are the Signing Certificate and Encrypting Certificate used for and what would be suitable certificates for a public facing service? Do I need 3 different ones?
The claims that WIF is built around are delivered via tokens.
Each token is signed to prove that it came from the expected STS.
AFAIK, there is no way to remove the signed component of a token (which makes sense as otherwise any third party could generate them and "pretend" that they came from the STS).
These tokens can also be encrypted. If you were running across https, the whole message would be encrypted with the IIS certificate and the token would itself be encrypted again with the WIF encrypting certificate. The token encryption is optional. When you use FedUtil, one of the questions is "Do you want token encryption?". If you say "No", it is not encrypted. If you say "Yes", it is encrypted and you are then asked for the certificate.
If you wanted, you could use the same certificate for both token encryption and signing. From a security perspective, it makes sense to use two.
So the "most secure" solution would use three certificates.
You get the certificates in the normal manner from a trusted issuer.
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 have some secrets that I would like to keep in Azure Key Vault. I know I can use a client id and certificate to authenticate with Key Vault instead of using a client and and secret following these steps:
Get or Create a Certificate
Associate the Certificate with an Azure AD application
Add code to your application to use the Certificate
Most examples use either makecert or New-SelfSignedCertificate to create the certificate. Is a self signed certificate problematic in this case for a production application? This is only for an application to authenticate with Azure Key Vault and it's not something a client will ever see in their browser.
If a self signed cert is still frowned upon in this case then is purchasing a cert from a trusted authority the same process as purchasing an SSL/TLS certificate? Is it even the same type of certificate?
There is (with some caveats) nothing inherently wrong with using a self-signed certificate. There is no difference from a pure crypto perspective between a purchased and a self-signed certificate. The sole difference is that a purchased certificate has been signed by one or more certificate authorities (CAs) who distribute their public keys with most browsers/operating systems/etc. This means that a user can have a much higher confidence that a purchased certificate is legitimate, while they must take a leap of faith to accept a self-signed certificate.
In your case, however, you seem to be able to control the client application, and actual users should never see this certificate. Therefore, you can use a self-signed certificate without worry, so long as you take precautions to prevent man-in-the-middle attacks (i.e. someone generating their own self-signed certificate and pretending to be you.). One of the most effective ways to do this is via certificate pinning. In essence, you ship the public key for your certificate with you client application, and your client application will only accept certificates that provide that public key. This makes it much more difficult for a malicious actor (who has not stolen your certificate) to preform a man-in-the-middle attack.
TL;DR: So long as you take steps to prevent man-in-the-middle attacks, and you keep your certificate secure, there is nothing wrong with using a self-signed and self-generated certificate to secure non-user-facing connections.
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 am using Azure ACS with my MVC4 client using passive redirection. I've configured Azure to issue JWT, and I'm using the new WIF JWT library for validating the token. This is all working just fine.
The problem that I am encountering is that Azure signs the JWT with the X.509 Certificate, rather than the Symmetric Key, which requires my MVC application to have the Certificate, which is annoying at the moment.
I know that the JWT support is in Beta, and that there are security issues with using a Symmetric Key (in that anyone with the Key could fake a token).
Is there some setting that I am missing? I tried making the Certificate the "Secondary" signing key in Azure, but this had no effect.
ACS chooses keys to sign a JWT in the following precedence order:
Relying party symmetric key
Relying party certificate
Service-wide certificate
What you don't see anywhere on this list is a Symmetric service key, because there are security issues with using a symmetric key between more than two entities.
What this means is that your key needs to be associated with the relying party, not the namespace, as in the following screenshot.
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