I'm building a PHP web app that uses AWS RDS. In order to make the connection encrypted, I need to download the SSL certificate from RDS and store it on the app server so that the app can use it. But I remember when I use SQL workbench it somehow knows how to connect with SSL to the RDS instance without me downloading the certificate and telling it where the certificate is stored. Also after reviewing the way how HTTPS works, I know that the client doesn't need to store a certificate the first time it connects to a server, it download the certificate itself. So my question is for my app to connect to RNS instance using SSL, why do I need to first download the cert and tell my app where it's stored? Shouldn't my app know how to get the certificate itself?
Certificate validation requires a trusted root CA. Trusted means that the CA is in the local trust store. Depending on what site you connect to and what certificate you get it might be a certificate issued by a CA you already trust or not. In the latter case you would need to explicitly get the so far untrusted CA certificate first and somehow treat it as trusted.
The need to explicitly import a CA as trusted is typically true for self-signed certificates which is usually considered bad practice but depending on the specific environment might make sense. It can also happen for company specific CA but these should better by rolled out to the various systems by an automated process. It might also happen when a misconfigured server does not send a required intermediate certificate, in which case it would be better to fix this server.
Note that you should not import arbitrary CA certificates and consider these trusted. Whoever owns this CA can issue arbitrary certificates even for existing domains like google.com and your application will then blindly trust these faked certificates too, making man in the middle attacks possible.
Related
I'm not quite understanding the necessity of certificate pinning in SSL connection establishment (to avoid Man in the Middle attacks).
SSL cert pinning requires embedding original server certificate in the host to verify with the one presented by server. what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
What is that I am missing here?
what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
There should be none and that's exactly the point of certificate pinning.
Without certificate pinning an application commonly accepts any certificate which matches the requested hostname and is issued by a locally trusted CA (certificate authority). Given that there are usually more than 100 CA in the local trust store it is sufficient that one of these got successfully attacked as in the case of DigiNotar in 2011. Thus it makes sense to limit the certificate you accept to a specific one, i.e. pinning.
Besides the certificate pinning by comparing the certificate received with a locally stored certificate there are other ways of pinning: for example one might just check against a fingerprint (hash) and not the full certificate. In case the certificate can expire it might be more useful to check only the public key and not the whole certificate because the public key is often kept on certificate renewal. Or one might pin to a specific CA which one considers trusted to issue certificates for this domain.
Note that to understand pinning you might need to understand how the authentication of the server works. One part of this is that the server certificate is validated (hostname, expiration, trust chain ...). But this is not enough since the certificate itself is public, i.e. everybody can get it and could send it inside the TLS handshake. Thus the other major part of the authentication is that the server proves that it is the owner of the certificate. This is done by signing some data using the private key matching the certificate. Since only the owner of the certificate should have the private key this proves ownership. Because of this anybody could embed the servers certificate for pinning but only the server itself can prove ownership of the certificate.
What is SSL pinning
Applications are configured to trust a select few certificates or certificate authority (CA), instead of the default behaviour: to trust all CAs that are pre-configured on the device/ machine. SSL pinning is not required.
Why use SSL Pinning (Why not to)
In many cases, the certificate returned by a server could be tampered as long as any Root (or intermediate root) CA was compromised (happens very rarely). Threat actors could use this compromised CA to generate a certificate for your website, and show visitors their website instead. This is bad. SSL pinning was designed to prevent this in some cases, but there are better ways (IMHO).
Having said that, I don' t know any website which uses SSL pinning so SSL pinning seems primarily discussed for mobile apps. It seems like SSL pinning only works when you can trust the source of the application (e.g. App Store, Play Store) Why? Because if you have to visit a website to get the cert, by then its too late (you might have already used a dodgy cert and accessed the fake website or was MITM'd). Therefore, it seems like the benefits Steffen mentioned are not so compelling, especially when there are better solutions already:
Better solution
I'm not sure if any-CA-compromise is a threat vector, even for banks. Instead, banks and other security conscious organisations will pick their CA wisely, and also configure a CAA record.
By using a CAA DNS record, they can restrict clients (e.g. browsers, mobile apps) to trust only certain certificates when accessing their specific website.
They pick the CA and create a cert only from this CA
They will have a backup plan for if a CA is compromised. Don't want to go into that here, but the backup plan for CAA records is IMHO much better than that of SSL pinning.
For example, Monzo.com (I used whatsmydns to find this) has a CAA record which restricts certificates to only 4 CAs (digicert, amazon, comodoca, buypass):
0 iodef "mailto:security#monzo.com"
0 issue "amazon.com"
0 issue "buypass.com"
0 issue "comodoca.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issuewild "amazon.com"
0 issuewild "comodoca.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
These are popular CAs which people trust, we hope they don't let us down. If they do, the whole internet would be a free for all. The only way to prevent this is to be your own CA/ use self-signed certificates.
Summary
I don't see how SSL pinning will become ubiquitous, especially since it adds more overhead (maintenance regarding ssl expiry, or trusting one CA anyway - SPoF, or emulating what a CAA record does but with additional code/ maintenance burden). It also only supports your pre-installed applications, not websites.
We use nginx for SSL termination and rotate ssl certificate yearly. But whenever we rotate we send notification to user about date and time when we are going to apply the change and they have to make changes on their end at same time. There are few enterprise tools which few customers use, and they need same certificate loaded in their trust store.
So I wanted to check if there is any way to deploy two certificates on one domain temporarily like for a week. For that period both the certificate works, so customers can move to newer certificate over that period. May be some kind of certificate chaining or something which can help us solve this problem.
PS: I am sorry if sounds too stupid, just want to listen others view on this problem.
Thanks,
GG
While it would be possible to send any number of certificates to the peer (that's what you do when sending intermediate certs) it is expected that the certificate matching the hostname is the first and the following are the chain certificates in proper order. A client will not just look into all the certificates and pick the ones which look best.
But it should be possible that you give the client the new certificate in advance and it can add this one to the list of trusted certificates, without replacing the old one. And as long as you serve the old certificate the client will find this as trusted, once you move over to the new one the client will find this as trusted too.
Even better might be to use your own CA to issue all the certificates. Then the client needs only once to install this CA as trusted and then it will automatically trust any new certificates issued by this CA, no matter if you rotate yearly or daily. This is how it works in the browsers, where google or whatever does not need to ship the new certificates to all browsers but instead these are signed by a CA trusted by the browser.
The certificate is binded exactly to the FQDN which the Users type on the address bar. If you procure a Public SSL certificates from the likes of Symantec , Digicert, Thawte, etc your clients need not update their certificate store reason being the Public Certificate Authority (CA) roots & intermediate certificates are well known and are very much a part of all the Leading OS certificate stores.
I am developing browser extension, that sends some data from currently browsed page to my backend server. User is aware of it, it is intended.
I don't want to cause any user-data exposure, when the user is e.g. on unsecured wifi. So I just want to ensure, the data and the url goes over the net encrypted and only my backend will see them.
Do I understand correctly, that any SSL certificate, even free one from StartSSL will do the trick?
What other side effects with free SSL certificate should I consider?
- will the user's http-client trust such a certificate?
Thanks.
The SSL certificate will do the trick as long as it can be validated. That means that the root certificate of the certificate chain needs to be within the trusted certificate store of the browser.
Furthermore, the certificate will have to be for the right address (URL), must not be revoked, CRL's and OCSP must be configured correctly etc. etc. In other words, the usual steps required to have your web-service certificate validated must be met.
I am working on a website that exposes an xml gateway that clients can submit an xml request to and get an xml response in return. The website/company has been purchased by a larger organization and has been migrated into their infrastructure. The existing production site is using an ssl certificate by a particular certificate authority but the larger organization uses certificates issued by a different certificate authority. We have tried run a test with one of their clients and they are getting an SSL handshake error. The original developer says that the only way to get it to work is to restore the original SSL certificate and not to use the new ones. I am looking for some guidance or direction to diagnose this issue, so any help would be appreciated.
What the developer says, from the description is sensible to me, but the problem is theirs.
To verify that this is exactly what is happening you can do a wireshark capture and then decode the flow as SSL. If the problem is that the client do not trust the certificate send by the server and reject the connection you will see it in the handshake in the wireshark.
If you use a java client you could run it with -Djavax.net.debug=ssl to see the ssl messages from within java.
If this is indeed the problem then you must configure the client's truststore to have the certificate send by the server (which is the original one).
If this configuration is possible of course... This depends on the application
UPDATE:
Well if you migrated to a new CA, i.e. you deploy a new certificate in your interface, then sorry to say, it is "your" -meaning the server side- error.
IMHO, if it is possible, you should redeploy the old certificate for a prespecified period, communicating to all the stakeholders that you plan to migrate to a new certificate signed by a new CA, so that the clients don't break
Then it is their responsibility, within that period, to "fix" their client apps to be able to accept the new certificate. This can be as simple as configuration i.e. importing the certificate to a truststore, to as "complicated" as to change code and rebuild the client app (e.g. if the new issued certificate does not have extensions that the code is verifying or the CN has changed etc).
If it is not possible to redeploy the old certificate then, you just have to communicate the change to all stakeholders and then, they should "fix" it accordingly (as mentioned above)
What are the best practices for updating client-side SSL certificates without user interaction?
To be more specific:
I have a server with SSL private key/public x.509 certificate.
All clients will communicate with this server through SSL.
In order to establish SSL connection all clients need to import the server's public certificate to their trusted locations (truststore).
Getting the server's certificate at (client) install time is not a problem because the installer can contact the server (by SSL) and get the server's public key (or the company's Root Certificate). After that the installer can show the certificate to the user for visual validation and this is secure enough.
What will happen after the server certificate (or the company CA) expires?
Or what will happen if the server certificate is accidentally changed?
What are the best practices to (automatically) update all clients with the new server SSL certificate (CA)? Having in mind that after installation the clients are background processes and the is not visual user interaction possible.
Of course the easiest way is to manually update all clients by the infrastructure administrator.
I'm wondering if there are some known good practices to automatically update the client's certificates without user intervention?
Ideally, your server certificates should be issued and signed by a trusted root CA certificate with a long lifetime (10 to 20 years). Just the root CA certificate would be installed on the client end.
The server certificate itself, even if you update it every year, would not need to be propogated to clients since the root signed it and is trusted.
If you're using self-signed certificates, this is why they are generally frowned upon from a certificate management perspective. When they expire or change, you need everyone to update - otherwise you'll get browser security warnings.