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.
Related
When I open the SSL details of an internal application inside network (Intranet enterprise application) - I see 3 levels of certificates? What does each level mean?
There is no specific definition of each "level".
The HTTPS world works using a PKIX model: each entity (here specifically website and their hostname) is authenticated by some X.509 certificate.
For the trust to happen this server certificate needs to be signed by another certificate, called an authority certificate that you trust.
Browsers are shipped with hundreds of default authority certificates. The system is built under the assumption that you trust the entities behind those certificates fully (yes, without having at any point seen all this list or explicitely given consent; you can remove all of them from your browser's or even OS trust store but then you will not be able anymore to connect anywhere through HTTPS and you will need to re-add them one by one), which means you accept as valid (besides other technical checks like on dates, etc.) any certificate signed by these authority certificates.
But for multiple technical and non technical reasons, authorities often do not sign end certificates directly but uses intermediary certificates (the "middle" level in your case if you want).
It does not change anything from the model above as the trust flows from the root and when you connect to a server it is responding with its own certificate plus any other intermediaries needed to reach back any trusted root.
Note that the depth may vary. Some authorities may issue end certificate directly (so you will have 2 "levels" in the output), some may use one intermediary (frequent case), some may use a cascade of intermediaries (intermediaries through some technical points in their certificate can be restricted to sign only some specific certificates like under specific names and so on), this is all up the certificate authority that issued the given end certificate you are looking at.
And when you deal with "self-signed" certificates, you do not have levels anymore because the certificate is signed by itself which means it is its own certificate authority, so it is alone in the list of certificates.
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'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.
I know how to create self-signed SSL certificates, but how must a certificate request be formulated so that the certifying authority grants the certificate the ability to sign certificates?
Let's say I am chief of networks operations in a company. Different IT departments have their own networks they can certify others to connect to, but I have to grant their certificates the ability to sign certificates rather than they creating their own self-signed certificates?
Most of the work involved in setting attributes and other pieces of information into a certificate is administrative.
You shouldn't worry much about the certificate request itself. Any decent CA will tear apart the certificate requests it receive to extract the public key and associate it with whatever pieces of information it wants to form the certificate. It should only insert pieces of information that (a) it has been able to verify by some other means (e.g. domain validation, or numerous paper forms, ...) and (b) it's willing to vouch for (and possibly be liable for to a degree, depending on the terms and conditions).
Some well known CAs have schemes to become an intermediate CA. They'll issue you with such a CA certificate. (Hopefully, it's hard to sign up for these schemes...)
If you're deploying your own internal CA and want intermediate CAs, the intermediate CA certificates you issue should have the cA boolean of the basic constraints extension set to true (see RFC 5280). (This is not so much an issue with the certificate requests, but with the certificates you issue.)
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.