Let's say we have a server only running REST API services, only on HTTPS.
The only consumer of the APIs is a mobile app.
Do we need certificate from CA or a self signed certificate is enough?
You will need to use a CA certificate. Otherwise, each mobile client will have to manually set your certificate as trusted.
You can potentially embed the certificate as trusted in the mobile app itself (assuming you distribute the app), however it will be a problem when the time comes to renew the certificate, or rekey/replace the certificate for whatever issue.
Using a globally trusted certificate is the way to go.
You can :
Keep a self-signed certificate, but then you have to pin the certificate, and you can't revoke it if the private key is compromised.
Use a home made certificate authorities, but then you have to pin the certificate, and manage the revocation process (maintain an OCSP or CRL).
Use a certificate from a trusted CA, revocation will be checked for you, and if you want additional security, you still can pin the certificate.
In my opinion, the use of a trusted CA is more secure and more simple.
Related
I'm studying Azure IoT Hub and trying to connect my device to IoT Hub with x.509 certificate.
It worked with self-signed cert, but the official suggestion is to purchase a root CA cert from a trusted third party to sign device cert.
Get an X.509 CA certificate
I did some research, but couldn't find where to purchase.
Can you give me a link? And how much will it cost?
You probably don't want a root CA cert, as those are not available to anyone but the certificate authorities themselves.
What you seem to be looking for, is a certificate signed by a root CA.
You can get one from let's encrypt, or from any of the commercial CAs like Verisign, Thawte, etc.
A word of warning. If you purchase a certificate from a certificate authority that has been signed by a trusted root and you intend to use that to sign device s' X.509 certificates for authentication, make sure that you do not purchase an end entity certificate. That type of certificate is incapable of signing another certificate and will not work. Make sure the certificate you get is capable of signing other certificates.
AWS has it's own CA. Because AWS thinks security is important and they are capable of a decent cloud product implementation.
Microsoft on the other hand is more worried about selling defender security E5 licenses, so security implementations are weak or require premium licenses. No account expiring, no Azure CA for devices.
This 3th party can fix your problem for IOT Hub.
https://www.globalsign.com/en/blog/integrate-microsoft-iot-azure-iot-hub-and-provisioning-service
https://www.deviceauthority.com/solutions/keyscaler-identities/
https://www.keyfactor.com/platform/iot-identity-platform/
Does setting ssl.client.auth=required mean that the client's certificate has to be added to the kafka truststore?
Regards,
Yash
Setting ssl.client.auth=required means that clients will need to pass SSL/TLS client authentication which is based on the truststore.
The truststore should contain certificates of trusted certification authorities. So if your clients use signed certificates, you should put the certificate of this certification authority into the truststore. That would allow all clients who have a certificate signed with this CA to authenticate.
If you use self-signed certificates or if you want only selected signed certificates to authenticate, you can put directly their certificates into the truststore. But they will be treated as trusted CAs - so if the client uses its client certificate as a CA and sign more certificates, these will be also able to authenticate. So this is not completely secure.
When I use self-sign certificate, I made a self-CA.cer and a server.cer, server.cer is for web service and self-CA.cer is added in client code. When I check certificate , I check if server.cer is from this self-CA.cer, right?
But, if I buy a CA certificate, what I only got is a server.cer generated from CA, right? and CA certificate can generate many server.cer, and they are all trusted , what I got is one from these .
In my client code, others said I only need to change my http to https, that's it ,after I buy CA. but how can I distinguish which server certificate is from my own server? I only want trust the server certificate from my own server.
if I buy a CA certificate
you can't buy a CA certificate (with small exception, which is not your case). You are purchasing an end-entity certificate which cannot be used to sign other certificates. It is controlled by a Basic Constraints certificate. Any standard validation code will reject any certificate that is signed by non-CA certificate due to Basic Constraints extension value (isCA attribute is set to False).
RFC 5280 -- Basic Constraints
If you trust a CA you trust all certs they issue (unless expired or revoked) -- that's how PKI works.
If that CA issues certs to other sites/servers, and you make HTTPS (or otherwise SSL/TLS or DTLS) connections to those other sites/severs, you will trust their certs and thus trust them.
But if you mean you want to trust only the specific cert issued to your server for your server, that's automatic. The cert issued to your server has your domain name in it, while the certs issued to other servers have their (different) names, and an HTTPS client like a browser will only trust a cert that is issued by a trusted CA and has the correct server name in it, so it will trust only your cert for your server, and will trust other certs only for the other servers those certs are issued to.
For much more detail, see Stack's Great Ursine Epic https://security.stackexchange.com/questions/20803/how-does-ssl-work/
I'm not clear about the authorization of certificate: a website has been associated with a certificate, say https://test.mysite.com. Do I have to install the certificate on my computer before access this url?
Another question is: every certificate is issued by a CA. If I have trusted a CA before by "installing" a cerficiate, will I trust the all the following certificates issued by the same CA?
Thanks!
It depends on the library or browser you are using to access to the URL but, if the certificate is issued by a trusted CA (one that your library or browser already trusts), the web site's certificate does not need to be installed before accessing the site.
If the CA is not trusted, there are two options. One is to trust the certificate. Browsing to the page will usually open a dialog where the user can choose to trust the certificate, for example. The second is to add the CA to the list of trusted CAs. On Windows, this is done by adding the CA's certificate to the "Trusted Root Authorities" certificate store. The latter case means any other certificate issued by the CA will also be trusted.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.