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.
Related
I have a portofolio website runing on a IIS Windows server if that matters.But some people complained that they get "website unsafe" when navigating the website.I personaly didnt get that error , and I tried the website on other diveces and they didnt get it either.
Could have something to do with SSL Certificate ? I didn't bought one ,but I have a self signed certificate according to ssl checker
.Do I need to buy a trusted SSL Certificate ? Or is there another problem ?
On my website i have a "Contact us" page with a web form that users should fill with name,email...
EDIT: I don't know if it's ok to post the website link here, if it's needed let me know .
EDIT: Link to website here.
This is a general problem with self-signed certificates, as the visitors of you website, or their browser, are not able to verify the identity of your server. The reason for this is, that there is no Certification Authority that signed it, thus the browser does not have a (root) certificate that is in the chain of trust linked to your certificate.
This problem with self-signed certificates is well explained in this post
The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.
When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).
It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.
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 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 have been reading up on the technical basics of how SSL works (which was surprisingly hard to find inside the ocean of laymen/non-technical articles/tutorial/videos out there). I have 3 small questions that in and of themselves felt too small to clutter SO with but as a whole I think provide some insight into how SSL works and address issues that don't seem to be well-documented:
Why (not when or how!) do SSL certificates expire? These are just public/private key pairs operating on a cipher/algorithm like AES. I assume there's a financial/business incentive behind the scenes here?!?
How many SSL certificates does an organization need? And before you say "that depends on your organization", I guess at the core of this question is: what driving factors make a company say, oh, I guess we're going to need another cert, or 10 more certs, etc. In other words: why is 1 cert often not sufficient for an organization??
Why does a company ask a CA for a root certificate and then get child certificates off of that root? What benefits does this "Certificate Tree" provide? (As opposed to just getting separate certs.)?
Thanks in advance!
1) Why do SSL certificates expire?
When a certificate expires, you're basically saying that this public/private keypair has been abandoned. Technically, you can still use this certificate to encrypt data, but the expiration date is there to mitigate revocations among other things. Additionally, however, in the X.509 spec there are specific reasons outlined for expiration:
4.1.2.5 Validity
The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
certificate.
CAs publish revocation status information about a certificate and that means they need to keep track of them. When a certificate expires, the CA has done their part for the term of the certificate and stops tracking information for that certificate. You are essentially paying the CA to say with authority that this certificate is valid.
There are other reasons for expiration too. If I was still using a certificate signed in 2002 (which would be possible), the level of encryption probably wouldn't be up to standards used today. By setting an endpoint for the certificate, you are also setting a date on which you need to upgrade.
Now, of course, I don't think you can deny one of the biggest motivators behind the expiration is money [citation needed], but there are at least some technical and reasonable ideas behind it.
2) How many SSL certificates does an organization need / what driving factors help them decide?
It does depend on your organization. A traditional SSL certificate is matched to a domain name. However, anything can be signed with a key pair (developer certificates, etc.). So, for SSL, it'll depend on the number of domains you want to protect. For a traditional cert, www.domain.com and example.domain.com are completely different entities. There are other types of certs that can purchased, like wildcard certs, etc. that will depend on the needs of your business. Seriously, you can get incredibly complex or incredibly simple. Here's a rundown on some of the basic and different types for protecting a website: SSL Certificate Types
3) What benefits does [having a] "Certificate Tree" provide, as opposed to just getting separate certs?
You are basically saying that you trust this CA to generate certificates. That's why browsers have to have the root CA installed to accept a certificate. They are saying, "I trust this authority has only signed certificates for valid and trusted sources."
In practice, it ends up not being the case as a lot of CAs don't rigorously check who they are giving certificates to before issuance. Not always, but it does mitigate some of the danger. The problem is when the CA root certificate private key is compromised because then anyone can fake a legitimate certificate.
Hopefully this answers some of your questions.
A friend of mine asked me why we pay so much for SSL certificates if everyone could theoretically issue one. Why indeed? And how do we judge if the little lock in the browser is really trustworthy?
Certificates are cryptographically signed by something called a Certificate Authority(CA), and each browser has a list of CAs it implicitly trusts. These CAs are entities that have a set of cryptographic keys that can be used to sign any certificate, often for a fee. Any certificate signed by a CA in the trusted list will give a lock on a browser, because it's proven to be "trusted" and belongs to that domain.
You can self-sign a certificate, but the browser will warn you that the signer is not trusted, either by showing a big error box before allowing you in, or showing a broken lock icon.
In addition, even a trusted certificate will give an error if it's used for the wrong domain, or is modified to include another domain. This is ensured because the certificate includes the domains it is allowed to be used for, and it also has a cryptographic checksum/fingerprint that ensures its integrity.
This is not 100% safe at the moment, as there is the possibility to fake CA certificates that use MD5, see this link: http://www.phreedom.org/research/rogue-ca/. Though it has to be noted that this is pretty hard, as they exploited a weakness in an already existing CA, which may or may not have been closed by now.
In essence, we trust the certificates as much as we trust that our browser providers know how to select "proper" CAs. Those CAs are only trusted on virtue of their reputation, as a single misstep theoretically would be a very heavy blow on their trustworthiness if detected.
The whole CA business is amazing. I've purchased a couple of certificates from rapidssl.com, and all the "proof" they required was:
I could receive mail to the domain.
I could answer my phone.
That was it. Keep in mind, when trusting the little locks in the browser.
First, some background on strong public/private key cryptography, which SSL is based on:
A key has two parts, the private part and the public part. The public key can be used to encrypt material that requires the private key to decrypt. This allows the use of open communication channels to communicate securely.
One important aspect of public/private key cryptography is that the private key can be used to digitally sign a message which can be verified using the public key. This gives the receiver of a message the ability to verify concretely that the message they received was sent by the sender (the holder of the key).
The key to SSL certificates is that encryption keys themselves can be digitally signed.
A "certificate" is composed of a private/public key pair as well as digitally signed data. When someone buys an SSL certificate they generate a private/public key and submit the public key to a Certification Authority (CA) to be signed. The CA performs an appropriate level of due diligence on the buyer of the SSL certificate and signs the certificate with their private key. The SSL certificate will be bound to a particular website or set of websites and is essentially the CA indicating that they trust the owner of the private key of the certificate to be the proper owner of those websites.
The root certificates (public keys and other meta-data) for trusted CAs are included by default in major shipping browsers and operating systems (in windows, type "certmgr.msc" into a run prompt to see the certificate manager). When you connect to a web server using SSL the server will send you its SSL certificate including the public key and other meta data, all of which is signed by the CA. Your browser is able to verify the validity of the certificate, through the signature and the preloaded root certificates. This creates a chain of trust between the CA and the web server you are connecting to.
Because we have to trust someone.
Trusted SSL certificates have signatures of trusted authorities. For example, VeriSign has a deal with Microsoft, that their certificate is built in your browser. So you can trust every page with a VeriSign trusted certificate.
This graphic really picks the point:
RA = Registration Authority
CA = Certification Authority
VA = Validation Authority
Rough outline: A user applies for a
certificate with his public key at a
registration authority (RA). The
latter confirms the user's identity to
the certification authority (CA) which
in turn issues the certificate. The
user can then digitally sign a
contract using his new certificate.
His identity is then checked by the
contracting party with a validation
authority (VA) which again receives
information about issued certificates
by the certification authority.
If you are not using one of the accepted CAs people will get a message box when accessing the site talking about an untrusted certificate. That won't help to generate traffic to the site.
The lock only means that the site owner showed a CA some kind of proof that he really is who he claims to be. You must judge on your own if you trust that person/site.
It's like a stranger showing you a photo ID. Do you trust him more because you know for sure his name is John Doe? Probably not.
But when people you trust told you: "John Doe" is a good guy. The proof that the guy in front of you actually IS "John Doe", than you might choose to trust him as well.
Why? Because you're paying to ride along on someone elses reputation.... to vouch for you.
Its all about whose validating your claim to be you. Despite some of the documentaries Ive watched lately, and the recession, I'm still more likely to believe corporate America when they confirm your identity to me, than I am the Russian mafia. Even though both can just as easily issue certificates.
The amount you pay is basically just (how much it costs them to secure that reputation and/or suppress any security breaches) + (however much they can afford to gouge the market as a margin %).
Now the barriers to entry are quite high, cos its really expensive to earn that trust, so theres not a lot of competition. Therefore chances are the price isn't going to fall anytime soon.... unless Sony or GE etc decide to play.
You pay for a certificate so that when you go HTTPS (which you should for anything a little sensitive) your clients don’t get big warnings and go call your support saying that you have infected them & al…
Very little security, lot of FUD.
If you have the possibility of giving your clients your own certificate directly, do it. But it is a rare case.
Let's create an attack scenario.
Suppose the DNS was corrupted and https://facebook.com/ points to attacker's IP.
You sit down to your PC and open Facebook to loose few minutes on pointless scrolling. And then BANG, Certificate invalid error shows on your screen. Attacker signed https://facebook.com/ with his own cert to make sure no one will leave his copied facebook page because it's not encrypted so it looks suspicious. If browser wouldn't check certificate's authority, then attacker could sign corrupted page with his cert and you won't be aware you're connecting to the wrong IP.
So the attacker has 2 options to choose from:
Sign corrupted facebook page with his cert, so users will see an error.
Don't use https on his corrupted page.
Certificates are built on a chain of trust, and if let anyone be a signing authority, we would be implicitly trusting everyone. It's a bit scary today though, since there are over 200 so called "trusted authorities" whose certs are built into your browser!
There is one free CA that I know of though: StartCom. They issue free SSL certs, but they are only accepted in Firefox, not IE. (Not sure about Safari or Opera).
The other answers have explained the CA-system. The perspectives project aims to deploy a new approach to SSL, where you can choose whom to trust: http://perspectives-project.org/