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.
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 are required to add certificate for https://www.googleapis.com/youtube/v3/videos to our trusted certificates on our servers for complying with security policies.
We noticed that the certificate expires on the 24th of November,2016. Can someone help with a support team mailing list which we can contact to get the new certificate in advance so that there is no outage for the functionality.
Thanks
I think you are missing a basic concept of TLS: the role of a certificate issuer.
You usually don't lock yourself to a specific certificate for a site and hope that somebody will provide you with the new certificate up front if the old certificate expires and that you then can change all your clients to accept this new certificate. This simply would not scale.
Instead you trust an issuer (CA - certificate agency) to issue a certificate for a specific site. Then you check for any certificate you got that the trust chain to your locally trusted certificate is fine and that the subject of the certificate matches the site you access. The same CA certificate (or at least the public key inside) will be used for many years to issue new certificates, contrary to leaf certificates which are only valid for 1..3 years or even a few month only to reduce the risk of compromise.
In summary: Don't expect anybody to tell you up front when they issue a new certificate because nobody will tell you. Instead do it like everybody else and trust a CA.
TL;DR: you can't. Validate the certificate using CA list.
Google already use a pinning mechanism in chrome:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
But www.googleapi.com is not pinned in that list (only translate.googleapis.com), it means google didn't ensure anything about his keys/certificate/certificate chain. So you can't pin it without taking the risk to break something, even before the renewal: they could change the certificate and/or the chain without notice.
Does anybody know whether it's feasible to have a csr signed by two CAs and deliver both certificates?
Reason for asking:
a server running several services (https, mail, imap, git, xmpp...) and i run a CA for it, also used for client certs (xmpp, mail encryption etc.).
This means users have to import th CA cert, which is ok for power users.
Some applications (mail and https) have to be accessible by regular (non-power?, common?) users, so it would be great to use a free ssl cert which is already installed in all common browsers for that (I think of startssl).
My first attempt is to get my CA cert signed by the official CA e.g. startssl, but its understandable that this does not work for free use.
So now I think about creating a csr for the common used services and have it signed by an official CA and my own CA, serving with both certificates, the official as "fallback".
or is there a smarter way?
You can't have a certificate signed by multiple CAs (there's only one issuer in the X.509 format). You can submit the same CSR to 2 CAs, but this will produce 2 distinct certificates (if that's your aim, it's usually better to have different key material, so different CSRs anyway).
If your clients support Server Name Indication (SNI), you could potentially server two distinct certificates on the same service, but the services would also need to have different names (otherwise, it's impossibly to distinguish which name is requested).
You're certainly over-complicating your problem by trying to use two distinct CAs or two certs on the same service on your server.
"Power users" will also certainly have the main commercial CAs in their trust anchors anyway. In this case, serving them a certificate signed by your own CA doesn't really bring any advantage. If their main difference is the fact they would come with a client-cert issued by your own CA, nothing prevents you from trusting your own CA (and therefore their client-certs) on your server, while still presenting a server certificate issued by a commercial CA. The trust anchors used by your server don't necessarily have anything to do with the trust anchors used by its clients.
I have a simple question (maybe stupid) and i didn't find any clear answer to it. If i get a certificate from a trusted signing company (like verisign...) for one of my server (web for instance), i'll have private an public keys. With this certificate can i set up my own intermediate CA and sign cert request and the be trusted by every one (i know that's shouldn't be..)? My real question is : what will prevent me for issuing certificate and how the company can garanty that nobody does ??
Thanking in advance!
The certificate issued for your web site is suitable for SSL/TLS and is not suitable for issuing other certificates (Key Usage field is different). Consequently while you technically can generate another certificate using yours as a CA, such generated certificate won't be trusted by properly implemented and configured validators (those that check Key Usage).
You are not paying verisign or other certificate organisation for the certificate publishing but for the certificate validation, this meens that they have web services that respond if your certificate is valid or not, if it is still active and not expired and your contact information as requested.
Unfortunatly this is something you have to live with it and pay them if you really need ssl over your site.
I have used a homemade certificate for my lan server and when i visit this https site a big red warning notifies me that this site is malicious and it has not a valid certificate. This doesn't bother me but I am sure that all of my clients would have freeked out if they see such a bold warning popping up to their browser.
what can you do? it's a companies' world
I want to use SSL (https) to secure communication. Is it possible to do it without buying a certificate of some sort?
You can use a self-signed certificate (google it) but your users will get a message saying the certificate is not valid. The traffic will still be encrypted, however.
The reason you have to pay a third party for a "valid" SSL certificate is that part of the purpose of an SSL certificate is to verify the authenticity of your server. If any body could issue an SSL cert with any information they wanted, what's to prevent me from setting up an SSL certificate using Walmart.com's contact information and tricking users into thinking my site is a branch of walmart.com?
In short, you can get the encryption part for free, but if you want to avoid browser identity warnings, you'll need to pay for a third party cert.
You can self sign a cert, or get one from cacert.org or a related free signing community. Most browsers will throw up warnings, so you shouldn't do it for production (if you are an ebusiness), but during development, or if you don't care about the warnings, it's a cheap alternative
As others have said, you can simply and easily use self-signed certificates or set up your own certificate authority (CA) and then issue as many certificates as you want. All these certificates are as valid as the "commercial" ones issued by the big CAs, so there is no technical difference between your certificate and the one from, say, verisign.
The reason most browsers and other client applications warn about your certificate is, that they do not know and therefore not trust your CA. Browsers usually come with hundreds of well-known CA certificates everyone automatically trusts (if thats a good thing, well...), so you don't get a warning when visiting amazon.com via HTTPS. In Firefox, you can go to "Preferences" > "Advanced" > "Encryption" > "View Certificates" to see which CAs or individual certificates your browser currently trusts.
In the end, it's a question of whom you and the users of your service trust. If your users know and trust you (say in company network or a small development team), they can add your CAs certificate to the trusted certificates in their browser. From then, every certificate issued by your own CA will generate no warning and will be trusted just like every other certificate.