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
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'm building my first web app and I have two questions about security.
I'll send and receive very sensitive data with POST request to my
api which will be hosted on Azure or AWS. Can I send and receive
data in plaintext over SSL, is it secure? I can access my
azure web site over https, is it secure enough or should I buy another
SSL sertificate?
I've searched a little bit and there are different types of SSL
certificates, I read some certificates provide green padlock or green address bar but I don't need these kinds of things since my web app only
will be available to my mobile app and there will be no content to browse. Only one page with download links to my mobile app in case someone finds this site. So all certificates are secure on same level for my situation?
P.S. I won't add custom domain name, if that's relevant.
Answering your questions one at a time;
Modern implementations of SSL are generally considered to be pretty
rock-solid; its used by banks, healthcare institutions, and major
internet companies. Sending data in plaintext, over SSL, is
safe enough for those applications, and trying to replace SSL with
your own encryption scheme is almost certainly more trouble than its worth.
You should probably get your own SSL certificate; I don't know what restrictions Azure has on https access, if any, and its always bad practice to rely on a key you cannot control.
SSL relies on networks of trust; browsers (and other internet applications) validate the certificates sites send them against a
set of trusted authorities. If the certificate has been approved
(signed with the authority's private key), the browser accepts the
certificate as genuine and uses it to negotiate an SSL connection
with the site without further complaint. This is what that green
padlock/address bar means; that a site has provided a valid
certificate signed by an authority the browser trusts. This doesn't
mean that a signed certificate is inherently more secure than an
unsigned certificate, however. Both use the same cryptographic
algorithms, and (can) have the same length keys, and the SSL
connections each can set up are equally secure. The difference
between the two is that you can't verify the "authenticity" of an
unsigned/self-signed certificate; an attacker could intercept the
connection and replace an unsigned certificate with their own
certificate, and the browser would have no way of telling if it got
the right certificate or not. You can overcome this problem in your
application, however, with a technique called "certificate
pinning".
Essentially, you package the public key for your certificate with
your application, and your application only accepts the certificate
associated with that key when setting up a connection.
Ultimately, it depends on your attacker model. Are you protecting this data from criminals and casual wiretappers? Or are you trying to hide it from government surveillance and intelligence agencies? For the former, an SSL certificate signed and issued by a reputable authority is more than sufficient. For the latter, you have to consider where your certificate is coming from, and who can access the root CA that issued it; it might be better to generate your own, and devise some further scheme on top of SSL.
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.
My company has external web api service and I want to make it secure using SSL certificate. This service is called by internal application only. Is it secure to use self-signed certiifcate in IIS on production?
Yes it is secure to use a self-signed certificate even.though it is not best practice for Production environment.
Indeed the Root CA will be unknown and the client cannot validate the issuer. Your client will have to accept such a certificate (this means you will have to handle the certification check yourself)
How to ignore the certificate check when ssl
If the API is used only internally, it is not a big deal. If you have some external consumers, you should really just go and buy a certificate.