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/
Related
There are two separate CA virtual machines (Windows Server 2012):
RootCA
SubCA - created/signed by RootCA
RootCA is off and offline (no network connectivity).
How to renew Microsoft SubCA?
SubCA is valid for more than a year now, but we want to plan ahead.
Root and Sub CAs are not connected to Windows domain, it is not for used for Active Directory.
SubCA is used to generate SSL certificates for out internal servers - Apache, Nginx, IIS, etc.
RootCA and SubCA certificates are trusted on Windows and Linux machines (both servers and workstations).
Is it necessary to add newly renewed SubCA certificate as trusted after renewinig it? Or it will be already trusted, but now it is just renewed?
The renewed SubCA will be trusted as it will be signed by the already trusted RootCA - that's how PKI works.
Never add the new SubCA certificate into your trust-store as it mustn't be explicitly trusted. It is only implicitly trusted because it's issuing CA (the Root in this case) is trusted. Remember that if you were to add it to the trust-store and you subsequently decided that the SubCA was compromised and therefore required revoking, you would have to manually remove it from all trust-stores - a laborious process.
Instead, you will need to give all subscribers this new SubCA certificate when you next renew their end-entity certificate so that they present the correct chain when relying parties connect (as required by the TLS protocol).
In the Windows world you can add it to the Intermediate CA store (not the Root CA store remember!) so that servers have it to hand when their end-entity certificate is renewed by the Sub CA. Windows will figure out which CA certificate to send when the end-entity certificate is renewed.
In the non-Windows world you have to read the documentation for the application to ascertain where the CA certificates should be installed. Quite often, they are appended to the file containing the end-entity certificate, but it can vary - so do check.
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.
I have an architecture where there is a single root CA and multiple sub-CA's. Each sub-CA publishes certificates for devices in it's "domain". Within each domain is a VPN gateway (Cisco router). I would like to determine if it is possible to devise a configuration where each domain's VPN gateway would be able to check to see if the connecting device's certificate has been revoked at it's domain's sub-CA or another of the other domain's sub-CAs. I'm also looking for the most efficient solution which would require as little configuration as possible when adding new domains.
Thanks!
A CRL or OCSP response has the serial number of the revoked certificate in a list, which is signed by the issuing CA or OCSP responder. This ensures that when I revoke certificate serial no 123456789 on my CA that the certificate with the same serial number but issued by your CA isn't revoked instead. Certificate serial numbers, although long, aren't globally unique.
From a security perspective, the ability to revoke another CA's certificates would just cause mayhem and the consequences would be dire.
The only CA that can revoke a certificate is the one that issued it.
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.