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.
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'm trying to secure my k8s cluster, and I'm looking at client-authentication authorization support for k8s. My requirement is that I want to be able to uniquely identify myself (e.g. client) to the k8s apiserver, but everything I read so far about client authentication is not the solution.
My understanding is that the server will just ensure that the client certificate provided is in fact signed by the certificate authority. What if a hacker gets another certificate signed by the same certificate authority (which isn't hard to do in my org) and uses that to talk to my server? It appears that popular orchestrations like Swarm and k8s support this option and touted it as most secure so there must be a reason for doing this. Can someone shed some light?
It is not only verified that the certificate is authorized by the CA. The client certificate also contains the Common Name (CN) which can be used with a simple ABAC Authorization to limit the access to specific users or groups.
Also it shouldn't be easy to get a signed certificate. IMO the access to the root CA should be very limited and it should be comprehensible who is allowed to sign certs and when it happened. Ideally the root CA should life on a offline host.
Beside that it sounds like the CA is also used for other purposes. If it is so, you could consider to create a separate root cert for the client authentication. You can use a different CA for the server certificate by setting different CA files for --client-ca-file and --tls-ca-file on the apiserver. That way you can restrict who is able to create client certificates and still verify the server identity with the CA of your organization (which might already be distributed on all org computers).
Other Authentication Methods
As mentioned Kubernetes also has some other authenication methods. The static token file and the static password file have the disadvantage that the secrets have to be stored plain text on the disk. Also the apiserver has to be restarted on every change.
Service account tokens are designated to be used by applications which run in the cluster.
OpenID might be a secure alternative to client certificates, but AFAIK it is way harder to set up. Especially when there is no OpenID server, yet.
I don't know much about the other authenication methods, but they look like they are intended for integrating with existing single-sign-on services.
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'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 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.