if i use an SSL certificate for my iOS or Android app to communicate with my server, can use any CA - ssl

If I use SSL for my app to communicate with my server, can I use any SSL certificate, like those issued by goDaddy? I understand the reason people buy Verisign certificates(which are terribly expensive) is that they are supported by all browsers. But if I have no browser component, and the communication is between my app and my services, can I go for a cheaper one?

How SSL works
The Goal of SSL Certificates is to ensure no Man In the Middle is earsdropping on your encrypted communication. When your app is connecting to your server, your server therefore presents a certificate which tells, that the used encryption key really belongs to your server. This certificate is cryptographicly signed by a trusted party, such that the man in the middle can not forge such a certiifcate. Your app has to know the cryptographic key of the trusted party in advance to verify this signature.
Use godaddy certificates
You can use any certificate made by a trusted party which is known by your app. If you include the godaddy cryptographic key (called root certificate) in your app you can use godaddy certificates.
Use your own zero cost certificate
For you and your app, you yourself can be a trusted party for certificate signing. You can use your own self generated certificate without paying anyone for it. You only need to include your own certificate in your app. You can find a tutorial on how to generate a self signed certificate at http://www.akadia.com/services/ssh_test_certificate.html .

Related

How to sign an application and a site with SSL

I have a question regarding signing with SSL. I need to sign an application (.exe) written in Delphi. At the same time I also want to sign an Internet Portal with which the application communicate. My question is: does signing services generally provide also the certificate for the application either the certificate for the site? Can you sign the application with the same certificate or do you need another certificate? Can you sign multiple applications with the same certificate?
Thanks in advance.
Alberto
You need 2 certificates: One for code signing (that is, signing the .exe) and one for SSL (for the website).
You can not sign the application using the same cert as your are using for SSL.
You can sign as many applications with your code signing certificate as you like.
You may or may not use the SSL cert for multiple hosts (e.g.: blog.domain.com, www.domain.com, chat.domina.com, static.domain.com...), this depends on the type of certificate you are using.
Also: Please note that you can get free SSL certificates (e.g.: LetsEncrypt provides them, and azure website can use free "managed" certs from microsoft.). However, to my knowledge, there are no free code signing certificates.

Why I need a SSL certificate?

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

Create my own intermediate cetification authority from commonly trusted certificate

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

Can I create my own root certificate to use for an SSL connection with Go? Is this safe?

I'm writing a simple client and server using Go. I don't want to pay for an SSL certificate, and I've read that self-signed certificates are useless for proving identity since an attacker could just MITM and provide his own self-signed certificate.
However, I've learned that I can have my client use whatever root certificates I want. Can I just create my own, have the client trust that, sign a certificate for my server, and connect securely while being protected from MITM attacks? If so, how do I create my own root certificate?
A self-signed certificate is a special case of deploying your own PKI (pushed to the extreme where you only have one certificate in that PKI).
Both can be used to prevent MITM attacks, provided that the client can verify the server certificate using trust anchors (certificates) it knows in advance (and has been configured with them in a trusted manner).
You can create your own CA and configure your client to use its root CA certificate or, if you only have a very limited set of servers, you can usually configure clients to trust a specific certificate directly (self-signed or not).
You may be interested in these questions for links to tools:
Solutions to sign certificates
Recommendations for a Certificate Management tool for Linux
OpenSSL's CA.pl (useful, but may lack general management interfaces)
Once you've understood the basic principles, the technical aspects are not necessarily difficult, but part of the real difficulty is in the administration of your CA.

Is it possible to use https (own-server) without paying anything?

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.