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 validate a client certificate in Azure API management using context.Request.Certificate.Verify() method.
I have tried the following steps:
I have created self signed root CA certificate and then created a
client certificate and key file.
Now from postman, I am trying to call a method attaching the client certificate. I have verified that the certificate is sent to APIM via trace.
Have uploaded the root CA certificate in APIM -> CA certificates. While uploading I
converted to ".cer" file as it is not accepting ".crt" file and set the Store as "Trusted root".
In APIM policy, have used the method to validate the client certificate via context.Request.Certificate.Verify().
Now, when I try to call APIM api with client certificate, the above method (step 4) is always coming as False, verified from apim trace. Not sure, what and where I am doing wrong things. Any help/guidance or any article is really helpful.
I faced the similar issues, Investigation Summary / Cause are below:
Later customer encountered issue again when they sent PFX certificate as a client certificate to APIM from Postman.
The self signed certificate CRL distribution list (Urls in certificate revocation lists) and Access information cannot be publicly reached (APIM is public hosted and not internal) hence certificate.verify fails
2 options to fix the issue
Purchase a certificate from a Public trusted CA
Use context.Request.Certificate.VerifyNoRevocation instead of context.Request.Certificate.Verify so that APIM will not check the revocation list during certificate.verify
Note:
If certificate.verify is a mandatory order from your security team, then you would have to purchase a certificate from trusted CA
o you need to VerifyNoRevocation since apim cannot retrieve revocation list information and VerifyNoRevocation will still perform verifying certificate path as well
For client certificate validation in Azure API management generally following steps are required.
Generate a root CA , intermediate CA along with the client certificates.
Upload the intermediate certificate which validate client certificates sent by the user.
You van utilize this guide to set up the CA.
I bougth a SSL certificate online from a seller today for my custom domain which redirected to the azure web application with cname.
I did created csr file with that domain let's call it app3.product.com by using IIS 8.And then created the .crt filel with that csr file.
After that i did found that i need the pfx file but i didn't have .key file so, i converted the .crt to .cer than uploaded it by azure portal.
The problem is Azure portal says,
No certificates match the selected hostname
Althogh my certificate issued as app3.product.com and the host name has the same domain name. It doesn't work.
I didn't include key file while i am creating the csr file also the subject of the certificate has some additional information by the issuer. The subject like app3.product.com, Certificate Issued By ... These may be the source of the issue.
Thank you in advance.
You need to include the private key. Otherwise your web server can not decrypt the data the clients (web browsers) are sending to it.
Explanation:
HTTPS/TLS/SSL are based on asymmetric cryptography which means that data gets encrypted with a so-called public key and can only be decrypted with the corresponding private key.
This means that your web server will send a certificate to the browsers which contains the domain name + the public key + a signature from a Certificate Authority (CA). The web browser then checks then if this certificate is valid (with a CA certificate) and uses the included public key to encrypt further data. Since your web server is the only one who knows the private key it can use it to decrypt the web browsers request. Actually the overall process is even a little bit more complex. You might want to have a look at the TLS handshake protocol to see how it works.
I need to create a csr file to give it to someone.
The csr file is for a SSL certificate for a azure web app.
When I google I find inconsistent information about where to generate the csr file.
Some sources say: I have to create the csr file on the server the web app is running.
In my case the server on azure is unknown. I can not run anything there...
Or is it ok to create the csr on my local pc with all company data + the subject filled out with the custom domain?
openssl is installed in the console, you can generate the files there. You will have to specify all of the settings necessary in the original command to openssl because it is supposed to prompt you with questions but it doesn't work at present. So something like this:
openssl req -new -newkey rsa:2048 -nodes -out yoursite_com.csr -keyout yoursite_com.key -subj "/C=US/ST=California/L=San Francisco/O=Your Site Inc./OU=Engineering/CN=yoursite.com"
once you have your csr you can't open it from the console, you actually have to use Kudu (click on Advanced Tools) to open the file and copy the contents.
You're able to create a cer-file with the help of the Certreq.exe or OpenSSL tool.
For more details, please have a look at the official documentation how to enable HTTPS for an app in Azure App Service.
Others have provided valuable insights on those facts:
That you can (and in case of Azure Web App, basically have to) generate the CSR on a different machine, than the target server (the one, which will be using the certificate).
Tools, which you can use to generate the CSR (e.g. openssl, DigiCert utility).
An alternative way to obtain certificate for Azure Web App (Azure App Certificate Service).
Maybe I'm missing something, but I do not see an answers on:
Why would you want (or even should) generate the CSR on the target machine?
Why don't you actually have to?
My approach to answering those two questions I would start with the fact, that generating CSR is actually a process, that produces two artifacts, where the obvious part - the request for certificate - is probably the less important one for this matter. The more important one, which also actually has to come first, is the RSA key pair being generated, where the public part of the pair is used in the CSR request, and the private one is the crucial part of the whole goal of using the certificates.
Although the key pair is usually being generated using entropy data based on the hardware, so specific to the machine you are using, the outcome (the key pair) may be used anywhere, as the key values are only mathematically bound to each other. The CSR content is based on the public key and the subject of the requested certificate, so again, there's nothing in there, which can't be used elsewhere. This explains why there's no technical limitation on actually generating the CSR (and keys) on a different machine/service, than the one, which will actually be using it, so the question number 2 is addressed.
The answer to the question number 1 comes from the crucial feature of the private key, which is being generated in the process. This crucial feature is that it should remain private. The ideal being only the sole user of the certificate identity being able to use it. That "user" would be the target service (the web server). When you generate the key elsewhere, you are responsible for protecting it on that environment and in transit to the target. This is often an unnecessary risk. The suggested solution is often to generate the key in the target certificate/key store, with private key protection, which prevents the private key from being extracted (exported) from the store. Even the target service (web server) will actually not be able to extract/read it (but will be able to use it). As the key pair is generated in the CSR creation process, this means that this process should be executed where that store is, and by that store features. This should answer this question. As a side note, the DigiCert tool as well as the IIS manager UI are using the Windows cert stores, which do add a protection layer for the private key, but they do mark the key as exportable, which allows key extraction. The OpenSSL tool (on Windows) generates the key outside of the Windows cert stores (as files), so you can easily access it, which is not that secure.
I've found this article: https://www.namecheap.com/support/knowledgebase/article.aspx/9854//how-to-generate-a-csr-code-on-a-windowsbased-server-without-iis-manager, which mentions 3 additional ways/tools for generating the CSR, where the first one (using Certificates snap-in in Microsoft Management Console) actually does allow you to mark the private key as not exportable.
Of course, in your case, the ability to take (e.g. export) the private key is crucial, as you have to generate the CSR elsewhere, as the Azure Web App cert store has currently no feature allowing generation of the CSR.
Instead of doing it manually, an option is to search through the extra services for "App Certificate Service" which will provide you with a wizard for buying an SSL certificate and then binding it to your application. It's much simpler and quicker than generating a CSR by hand, and it's a lot less confusing as well. The documentation was verbose and wasn't really clear on whether or not we're supposed to remote into the server and generate the CSR there, etc, so I highly suggest doing it via the App Certificate Service.
For example, do it in the command line with ssl in your local machine:
create csr:
openssl req -new -newkey rsa:2048 -nodes -keyout yourprivate.key -out yourdomainname.csr
here you already have generated the crt and bundle file:
next step to create pfx: openssl pkcs12 -export -out certificate.pfx -inkey yourprivate.key -in nameofyourcertfile.crt -certfile nameofyourtcacertfile.ca-bundle
after you can upload your certificate.pfx file into Azure App Services and bind to your custom domain
You have to buy a certificate and setup for your naked and www domain, because Azure currently only provide free, managed certificate for www domain.
I have website hosted on IIS. My main issue is that I want only users with a specific certificate installed to be able to access the site. I tried to follow some tutorials but I can't find anyone covering both server and client side, since I can't get it to work.
I have some questions to the main issue:
What kind of certificate should I use (domain/selfed signed in IIS 7.5)? I do have access to a Active Directory Certificate Services where I can create other types of certificates (CA), but the problem is when trying to import them to my IIS ("certificate cannot be used as an ssl server certificate")
I would like to use a CA certificate, but is that possible when using IIS? Or do I need to write all the code the check if the user has the right certificate?
When created a certificate for the website (e.g. though IIS)..How do I create user certificates that are trusted by the server certificate?
As you may noticed by now I'm not sure how to do all of this, and would really like some help..
Server should use SSL server certificate. This certificate has to have Server Authentication extension in Extended key usage. Server certificate should have SAN extension (Subject alternative name) with domain name of server as DNS name (i.e. somesite.com)
CA certificate has to be imported to Trusted root store (preferably Local Machine) on both server and client machines.
Client certificate should contain Client Authentication extension in Extended key usage.
All EndEntity (client and server) certificates should have CRL distribution point in them where there is URL to CRL that is issued by CA. CRL has to be accessible by both client and server and should be always valid.
You can use XCA for training purposes. It has a nice GUI and it has templates for CA, SSL server and SSL client certificates by default. Then you can mimic these certificates in your Active Directory Certificate Services. Documentation and some guides can be found here.