I made an application, which communicates over the. net SSLStream, and for developing I used makecert.exe to create a self signed ssl certificate. Now Ive read in some microsoft article, that makecert should be used for testing only.
Now my question is: is the application safe with this cert, or which program can i make a safe and comparible cert?Any help will be greatly appreciated
Edit: The self signed Certificate is hardcoded into the client application and it compares it everytime it establish a connection, so man-in-the-middle attack couldnt work, but how random are the makecert Certificates?
I would recommend using OpenSSL to create a self-signed certificate used for production environment. I've never made thoughts about makecert.exe. To be honest: You want to achieve an encrypted transfer of your data using SSL between your Application and the server.
The hole certificate wont be displayed to the "user/customer". The only reason nowadays is to embedd a badge with "this is a secure page" to the page on which SSL is enabled.
If you are looking for this, you will definitely need a signed Certificate from a CA. If you are thinking about this, i recommend StartSSL, because it's far the cheapest and offers you for one time validation nearly unlimited wildcard certificates. Its trusted by microsoft and you can create a code-signing-cerficiate for free. (Onetime fee for validation only).
Concerning the randomness and security of the certificate:
If you are validating the fingerprint of the certificate you are connecting to, there should be less security concerns. (i.e. Fiddler won't work this way).
SSL is based on RSA Algorithm so when generating a private/public keypair with a keysize of 2048 or even 4096 (max. on StartSSL) there shouldn't be any security concerns. How to create the Certificate you will find here If you wont trust RSA, you shoudn't trust anyone ;)
Keep in mind that most universities using self signed certificates created using OpenSSL. Its now FIPS certificated and allowes you a wide bunch of settings to achieve fit your system.
It's safe if you find some secure way to get the certificate to everyone who uses your application. Otherwise, they'll have no way to know they're really talking to your application. Anyone else can run makecert just like you did, and nobody will have any way to know whether they're really talking to you. A certificate issued by a CA bind your identity to a certificate, allowing clients to know they're really talking to the right service.
When you punch https://www.amazon.com into your browser, how do you know you're sending your credit card information to Amazon and not an imposter? Well, Amazon has a certificate that was issued for www.amazon.com by a certification authority. An imposter could not get such a certificate -- the authority wouldn't issue it.
But if Amazon used a self-signed certificate ... well, anyone can do that. So how would I know I was actually talking to Amazon? I would have to know ahead of time which self-signed certificate that claimed to be for www.amazon.com was the right one. I wouldn't have a CA's stamp of approval to tell me.
you hardcoded your password (as a long cert) into your application, and you are asking if it's safe?
all I need is a copy of your code or wherever you stored it and I can hack all the apps you ever write. plus you cannot update or change it.
Self-signed certificates say essentially "I certify that I am I. Signed: I". Look up how to set up you own certificate authority (it depends on your choosen environment, and there are several options). Use that authority to issue certificates, and set the servers and clients to trust your CA. No need to pay $$$$ for them, plus you know exactly under what conditions you hand out certificates.
Related
I'm currently developing a graph app for neo4j desktop. From what i figured out, app should be signed with neo4j#code-signer (which utilizes node-forge i presume).
It needs a certificate and private key (and password probably).
What i can't figure out is, what kind of certificate is actually needed?
I signed my app with self-signed certificate which produced a big untrusted warning in neo4j desktop (touche, i should have known).
I used my ssl key which enabled my HTTPS, but this produced an error in neo4j desktop:
Certificate keyUsage or basicConstraints conflict or indicate that
the certificate is not a CA. If the certificate is the only one in the
chain or isn't the first then the certificate must be a valid CA.
Both options did produce signature.pem file.
Do i need to buy a Code Signing Certificate for this? If so, standard or EV?
Any help would be greatly appreciated!
Maybe this is going to help somebody:
There wasn't any issue with my certificates.
I got an answer from neo4j offical, that they are (at the time being) signing apps internaly, and that there is no automated way to do this (yet).
I have a short question: why do I need a SSL certificate (I mean only the certificate not the SSL connection)?
In my case Google Chrome deteced, that the connection is encrypted and secure, but everything is red because I created the certificate by myself.
Why I need a SSL certificate, if the connection is secure?
Just because traffic to 192.168.xxx.xxx doesn't leave the boundary of your network doesn't mean that it's safe.
Especially if you have BYODs attached to the network (and even if not, you don't want to be a hard shell with a juicy interior), someone can bring a compromised laptop or phone, attach it to the network, and a virus can intercept everything going on the network (see firesheep).
So you have to assume that the network is malicious - treat your LAN as if it were the internet.
So now the question goes back - why can't I rely on a self-signed certificate (both on a local network as well as the internet)?
Well, what are you protecting against? TLS (SSL) protects against two things:
Interception - even if I MITM you (I become your router), I can't read what you're sending and receiving (so I can't read your Credit Card numbers or password)
Spoofing - I can't inject code between you and the server.
So how does it work?
I connect to the server and get a certificate signed by a CA. This CA is considered trusted by the browser (they have to go through all kinds of audits to get that trust, and they get evicted if they break it). They verify that you control the server and then sign your public key.
So when the client gets the signed public key from the server, he knows he's going to encrypt a message that only the destination server can decrypt, as the MITM wouldn't be able to substitute his own public key for the server's (his public key wouldn't be signed by a CA).
Now you can communicate securely with the server.
What would happen if the browser would accept any SSL cert (self signed)?
Remember how the browser can tell the official cert from a fake MITM cert? By being signed by a CA. If there's no CA, there's literally no way for the browser to know if it's talking to the official server or a MITM.
So self-signed certs are a big no-no.
What you can do, though, is you can generate a cert and make it a "root" cert (practically, start your own CA for your internal computers). You can then load it into your browsers CA store and you'll be able to communicate through SSL without having to go through something like letsencrypt (which, by the way, is how enterprise network monitoring tools work).
In cryptography, a certificate authority or certification authority
(CA) is an entity that issues digital certificates. A digital
certificate certifies the ownership of a public key by the named
subject of the certificate. This allows others (relying parties) to
rely upon signatures or on assertions made about the private key that
corresponds to the certified public key. A CA acts as a trusted third
party—trusted both by the subject (owner) of the certificate and by
the party relying upon the certificate. The format of these
certificates is specified by the X.509 standard.
(from https://en.wikipedia.org/wiki/Certificate_authority)
You are not a trusted CA. Basically, if you sign your own certificate then there is no one that is able to vouch that the server is truly what it is. If you had a valid, trusted third party vouch for you then the certificate would be "valid."
Having a self-signed certificate doesn't necessarily mean that the website is dangerous, its just that the identity of the server can't be verified and thus it is more risky for the vistor.
Self-created or Self Signing Certificate are not trusted by all browsers. As we know at this time all browsers are more strict towards security. Let’s be clear about something right up front, the browsers do not trust you. Period.
It may seem harsh but it’s just a fact, browsers’ jobs are to surf the internet while protecting their users and that requires them to be skeptical of everyone or everything.
The browsers do, however, trust a small set of recognized Certificate Authorities. This is because those CA’s follow certain guidelines, make available certain information are regular partners with the browsers. There’s even a forum, called the CA/B forum, where the CA’s and Browsers meet to discuss baseline requirements and new rules that all CA’s must abide to continue being recognized.
It’s highly regulated.
And you are not a part of the CA/B forum.
The better option is to obtain an SSL Certificate from a trusted certificate authority.
Here's what you need to know about a Self Signed SSL Certificate
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.
I'm developing software which will be deployed using clickonce (on the website foo.com), and which will then connect to my server using WCF with an encrypted transport
So I need an SSL certificate which will :
Identify my foo.com website has really being my website
Identify the exe I deploy using clickonce as being genuine
Identify my application server has really being my application server.
I also want my SSL certificate to be signed by an authority known to the public (ie, firefox or windows won't ask the user to install the authority's certificate first !)
What SSL certificate would you buy?
I've browsed the Verisign website, the "Secure Site EV" certificate costs 1150€ a year (the "Pro" version seems useful only for compatibility with older browsers)
It sounds like you're looking for two different types of certificates:
1 - SSL Certificate - for authentication of your website/application server.
2 - Code Signing Certificate - for integrity/authentication of the exe you deliver.
Typically those are two different certificates, with two different certificate profiles. At the very least, you need one certificate with two different key usages or extended key usages.
A few thoughts in no specific order:
Check your targeted browsers, they should each have a set of preconfigured root certificates - those are the most widely recognized public certificate sources. I'd probably check both Firefox and IE. Certificate vendors known to me as big names are - Versign, GeoTrust, RSA, Thawte, Entrust. But there's also GoDaddy and many others. Anything that comes in the delivered browser as a Trusted Root Certificate, will allow you to connect to your users without additional greif.
I suggest Googling for both "code signing certificate" and "SSL certificate".
How you configure your site will determine whether or not your website is validated or your authentication server is validated. If the certificate is stored on the apps server, then your user is getting SSL encryption all the way to the server. But many sites put the SSL certificate a little farther forward - like on a firewall, and then stage a collection of apps servers behind it. I don't see a security flaw in that, so long as the networking is carefully configured. To the outside users, both configurations will look the same - they'll get the lock on their browsers and a certificate that tells them that www.foo.com is offering it's credentials.
I'm seeing pretty great deals for SSL Certificates:
- GoDaddy - $12.99
- Register.com - $14.99
But they aren't necessarily code signing certifiates. For example, while GoDaddy's SSL Cert is $12.99, their code signing certs are $199.99! That's part of many certificate vendors business models - lure you in with cheap SSL Certs, and make you pay for code signing. A case could be made that code signing certificates are relatively higher liability. But also... they have to subsidize the cheap SSL certs somehow.
Theoretically, it should be possible to make a certificate that does both code signing and SSL, but I'm not sure you want that. If something should happen, it would be nice to be able to isolate the two functions. Also, I'm pretty sure you'd have to call the certificate vendors and ask if they did this, and if they don't, having them do it will likely jack up the price quite high.
As far as vendor, things to consider:
The technology is pretty much all the same. These days, aim for a minimum of 128 bit keys, I'd probably bump it up to 256, but I'm paranoid.
Beyond browser acceptabiliy, the only reason to pay more would be name recognition. Among the paranoid security wonks, I'd expect RSA, Thawte, Verisign and GeoTrust to have very good reputations. Probably EnTrust, too. This probably only matters if you are dealing with a security focused product. I think your average user will not be so aware.
From a security geek perspective - you're only as safe as the security of your Root CA (Certificate Authority). For the truly paranoid, the thing to do would be to dig into the background material of how the company hosts its root and issuing CAs, how are they physically securited? network security? personnel access control? Also - do they have public CRLs (Certificate Revocation Lists), how do you get a cert revoked? Do they offer OCSP (Online Certificate Status Protocol)? How do they check out certificate requestors to be sure they are giving the right cert to the right person? ... All this stuff really matters if you are offering something that must be highly secure. Things like medical records, financial managment applications, tax information, etc should be highly protected. Most web apps aren't so high risk and probably don't require this degree of scrutiny.
On that last bullet - if you dig into the Verisigns of the world - the very expensive certs - you're likely to see the value. They have a massive infrastructure and take the security of their CAs very seriously. I'm not so sure about the super-cheap hosting services. That said, if your risk is low, US$300 for an SSL Cert doesn't make much sense compared to US$12.99!!
So for web site / application servers you need an SSL certificate. You do not need an EV certificate. I've used ones from QuickSSL for this, as unlike some of the other cheap certificate providers they don't require the installation of an intermediate certificate on the server - that's a no-one for me.
For signing applications that's a different type of certificate altogether (kind of, it's still an X509 certificate, but the one you use for your web site is not one you can use to sign an application). You need an authenticode signing certificate from the likes of Verisign or Globalsign. These are a magnitude more expensive than a plain old SSL certificate and require you to be an incorporated company and produce those documents.
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/