Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I am building a buy-system and i was told to set up an SSL certificate on my web-server to work with bank operations.
I am new to this and i don't exactly understand the difference between OpenSSL (which is free and opensourced) and SSL certificates, that are needed to be bought (thawte.com).
I guess OpenSSL is smth like tool to create a keys (ive alredy done this for firstdata.com), but if i buy ssl certificate on thawte.com and install it ill have my web-site running over https?
Can i use free openSSL to work with banks? Or i have to buy one?
The biggest difference between a self-issued (with OpenSSL) certificate and one you buy from thawte (or somewhere else) is that of trust. If you want your users to use access your ssl enabled website without being prompted for "do you trust the certificate from this issuer?" you need to buy a certificate from a trusted certification authority, such as thawte or one of the others.
Your website will run over https with any old x.509 certificate so if you only have a few people accessing your ssl site you may convince them to trust your self-issued certificate and save the money for the certificate.
OpenSSL is a tool and a library that can be used to generate certificate requests (CSR), self-signed certificates and issue certificates from a CA (if it's a CA you control of course).
There are a number of pre-trusted certification authorities embedded in most browsers. They issue certificates by signing the certificate they give you (coming from your certificate request). In turn, the certificates they issue can be verified by your users' browsers against their (issuing) CA certificate because it's shipped with them by default.
You can generate your own CA and issue certificates yourself, but the problem is that your CA certificate won't be trusted by default in most browsers, so it's worthless unless you make your users import it explicitly (which is fine for corporate CAs for example, but is impractical in general). A self-signed certificate is a special case of this: it's the root CA certificate you generate or a one-off certificate for a given machine; either way, you'd have to import it explicitly.
Some pre-trusted CAs will let you use OpenSSL to generate the certificate request as part of their procedure, but they may also offer other procedures relying on other tools. Which tool you or they use doesn't really matter. What you want is a certificate issued by a CA your remote party will trust.
You can sign up for free and generate free SSL certificate for your web site, at least for the first year, on StartSSL. Their site shows Weekend Maintenance now, but it will be available later. I was able to get free SSL certificate from them. This certificate is signed by Startcom certification authority which is trusted, according to their site.
Related
Why does self signed SSL certs throw an unsafe warning? They actually have a smaller attack profile, and not as easily cracked like commercial ssl from a CA. So in reality, a third party cert is more unsafe than a self signed one. Even the wiki page says this: https://en.wikipedia.org/wiki/Self-signed_certificate
A self-signed certificate does not create a security warning if it is configured as trusted in the browser. If it is not known as trusted yet the browser has no way to find out who issued the certificate: it can be the original certificate from the target server or it can be a certificate created by man-in-the-middle attacker. And that's why it is throwing a security warning.
With a CA signed certificate instead the browser can forward the trust it has in the CA (i.e. it is in the local trust store) to the certificates issued by this CA. This means does not need any more to trust every new certificate explicitly up-front but it is enough to trust the specific CA which signed the certificate. This makes the process of rolling out certificates much simpler.
Of course, the risk of the CA model is that one might put too much trust into a CA. The problem of the self-signed model is that you have to find a way to distribute the certificate before connecting to a site in a secure way to the browser - which means that you somehow need to trust this secure distribution of the certificate and that you will run into the same or even worse problems with this than you have in the CA model.
Self-signed carts throw an unsafe warning because your computer does not trust your CA, but (instructions different depending on the environment) you can set your computer to trust your CA.
I've been googling like mad trying to figure this out, but the answer doesn't seem to be clear, or at least, it seems like there are contradictory answers.
I'm tasked with setting up an Apache web server with 2Way SSL authentication. We use verisign to get our certificates, so we have a certificate for the web instance with the correct hostname details, signed by verisign, and an intermediate certificate from verisign. This all works very well.
Now, we need to set up a 2Way SSL connection. The initial expectation is that the client will manage their own certificates, and provide them to us for authentication. More than one client may be connecting, and they should each have access to different resources when they connect.
From what I've read, I'm not sure how this would be done...
This is a pretty good overview, but in this situation, they are using self-signed certificates: https://security.stackexchange.com/questions/34897/configure-ssl-mutual-two-way-authentication
Using these details, it would seem like we would have to make the trusted CA point to the certificate authority that signs the client's certificate.
Is it possible to use the client certificate as the trusted CA (even though it isn't self signed, but signed by a CA) or would we have to put a trusted CA from their signer (and at that point, would a CA bundle that includes all the client certificate authority CAs work?) on the server and then use the SSLRequire statements to limit access to specific details of the certificate?
As a followup, can we use the SSL Certificate that we get from verisign to sign client certificates?
So, after several more hours on google, and some testing, I was able to figure out what I needed to.
If I want to use a certificate signed by verisign or some other public CA, I would have to copy their public intermediate certificate (the one that they use to sign the client certs) to my server and specify it as the SSLCACertificateFile in the configuration. The caveat is that then any cert signed by that CA would be accepted, and that's where the SSLRequire directives can used to narrow that down to specific certificates.
Using the SSLVerifyClient optional_no_ca directive would make it assume that the cert is trusted, even if it isn't, and then I would have to use SSLRequire directives to verify the details are correct, however, anybody could create and sign their own certificate with those details and there would be no way to tell.
Creating my own self signed CA certificate, and then using that to sign the client certificates and issuing them to the clients is the only way to both ensure that the cert isn't a forgery and not requiring SSLRequire directives to ensure that only the people that I specify can connect.
Please comment/correct me if I'm wrong on any of this.
Use:
SSLVerifyClient optional_no_ca
In your Apache config. This will request the client certificate but not validate it against a CA. It will then be up to your local script to examine the resulting environment variables set by Apache such as 'SSL_SERVER_S_DN' and decide whether to allow the request or not.
These mod_ssl environment variables are also what your code needs to look at when determining what resources the client can access.
The full documentation is here mod_ssl although you probably found that already.
A note on client certificates. If you did want to use a CA and leave it to the clients, they may all use different CA's and you would have a job maintaining them all on your server. It would be much better to trust a single CA.
The advantage would be that then you could use the build in SSL support to do all your certificate checks and not write your own solution.
You could enforce a single CA by specifying an on-line provider and using email signing certificates to identify clients. These would work fine, just the Certificate Subject would be an email address instead of a domain name.
Or you could set up your own CA and sign client certificates yourself. This is not too difficult and gives you complete control. Either route would require you to add the CA root certificate (plus intermediates) to a file Apache can read and point 'SSLCACertificateFile' to it.
A certificate authority is supposed to verify a website is truly who they say they are, right. But certificate authorities sign there own certificates. So those certs are self signed. Is there a way I can find out if the self signed certificates they use on their website is reputable and trustable?
You have to trust the CA who issued the certificate. Otherwise, we encounter the classic chicken-egg problem where there is no concrete boundary for trust and certainty.
Once you trust the CA issuer, you can check whether the certificate you have was actually issued by the concerned CA by writing the following on a command line:
$ openssl verify -verbose -CAfile cacert.pem server.crt
Expected Output: server.crt: OK
If you get any other message, the certificate was not issued by that CA.
Visit https://kb.wisc.edu/middleware/page.php?id=4543 for more info
No, you just trust them! The most common way is to follow the herd... for example, extracting them from the browsers (http://curl.haxx.se/docs/caextract.html). We are always assuming the browsers are verifying it for us... as well as the operating systems...
Is there a way [you] can find out if the self signed certificates they use
on their website is reputable and trustable?
You can research the certificate authority yourself.
Some people may not trust a certificate authority, including Google. Google posted a list of authorities they did not trust back in May of 2016:
https://www.theregister.co.uk/2016/03/23/google_now_publishing_a_list_of_cas_it_doesnt_trust/
You either have to trust that the pre-installed certificates that came with your tools (web browser, etc) are trusted by the producers of those tools, or you can do some research and see if you really trust them yourself. It's basically like asking how you can trust anyone or anything. Can I trust you?
I trust the CA's that come installed with my browser because well, if I can't trust them then we all have a problem and that problem is bigger than me. I think it's good to ask questions like this and I wonder if anyone other than Google are questioning certificate authorities.
My webhosting company offer free shared ssl certificates that I would like to take advantage off but here's the issue:
the SSL url looks like this
https://web125.secure-secure.co.uk/myurl.com
I'm worried that when my customers make a purchase and they see that the URL isnt myurl.com they might be cautious or hesitant to continue the transaction.
so is it possible to map the ssl domain to https://secure.myurl.com
if not, are there any alternatives (apart from obviously buying my own certificate)
No it is not possible. The only alternative is to pay for a certificate unless you don't mind your users getting warnings in their browser.
The reason it is free is because your hosting company have paid for a wildcard certificate from a Certification Authority (CA) i.e. *.secure-secure.co.uk in which they can have any sub-domain. e.g. mycompany.secure-secure.co.uk.
If you want a certificate for your own domain e.g. mycompany.co.uk or you want a wildcard certificate to do stuff like services.mycompany.co.uk or extranet.mycompany.co.uk then you need to buy one, a wildcard certificate will be more expensive.
A certificate can only be used to validate a particular URL so you are basically paying a trusted source e.g. a Certification Authority such as VeriSign or DigiCert to vouch for your identity so users can know that when they hit https://www.mycompany.co.uk that traffic is encrypted and only the owner of mycompany.co.uk can decrypt it.
You're unlikely to a find a free source for valid SSL Certificates because the Certification Authorities will have had to pay to have their own identity verified and probably had to pay to have their own certificates built into operating systems to create a chain of trust. When you don't have a chain of trust or when a certificate URL does't match the URL you are visiting, this is when you get the big scary warning in your browser.
I'm a beginner in OpenSSL tools. I don't understand some concepts. Can you explain these concepts to me?
I want to understand concepts such as CA,Self-Signed Certificate or any concept for better understanding.
(Sorry if I am using the wrong terminology or grammar, I am learning english language.)
The purpose of certificates is to assert a piece of information in a way that you can verify. Public key certificates, more specifically X.509 certificates in this context, assert the binding between a public key, identifiers (the Subject Distinguished Name and/or Subject Alternative Names) and various other attributes. Altogether, these pieces of informations are signed so as to form the certificate.
X.509 certificates have both an issuer and a subject. The subject is the identifier representing who or what that certificate identifies (and who or what owns the private key matching the public key within this certificate). The issuer represents the identifier of the person or organisation that what used their private key to sign this certificate.
Certificate usage can be broadly split into two different categories: certificates that are used for a specific application or service (e.g. authenticating an SSL/TLS server), and certificates that are used to prove the validity of other certificates.
For the latter, certificates are used as building blocks of Public Key Infrastructures (PKIs). A Certification Authority (CA) is an institution that issues certificates: it signs the assertion that binds the public key in the certificate to the subject. When doing so, it puts its own name as the issuer name in the certificate it issues.
If you compare a certificate to a passport (which binds together your picture and your name), the CA would be your passport authority: those who actually certify that what the passport says is true, for others to be able to verify it.
Trusting a CA allows you to trust the certificates it has issued. You can build a chain of trust between a CA you trust and certificates issued by this CAs which you haven't seen before.
Along with this comes a "bootstrapping" problem: how do you trust the CAs themselves?
Self-signed certificates are certificates where the issuer and the subject are identical; they are signed with the private key matching the public key they contain. They are at the top of the chain of trust. They tend to be CA certificates (unless bespoke for a particular service, which you wouldn't be able to trust without external verification).
CA certificates are certificates that can be used for issuing/validating other certificates. (They can be intermediate CA certificates if they are in the middle of the chain between a root/self-signed CA certificate and a certificate you wish to verify.) The rules defining how certificates can be used to verify other certificates are defined in the PKIX specification (RFC 3280/5280).
Browsers and operating systems come with a pre-installed list of CA certificates that you trust by default. These are mostly commercial CAs which check the information about the service in the certificate, often for a fee. In counterpart, you can trust the content of the certificates they issue (most of the time, it's not a perfect system). There is a "leap of faith" involved here, since you need to trust the browser/OS to have included only reputable CA certificates.
If you use openssl s_client and you see a message like "self-signed certificate in the chain" or "unable to verify certificate", it doesn't necessarily mean that something is wrong, but openssl doesn't use a pre-defined list of trusted CA certificates by default. Most of its command have an options like -CAfile or CApath that allow you to specify which CA certificates you are willing to trust.
Self-signed certificates for a service are a specific case, whereby the service self-asserted its content. You generally have no way of verifying the authenticity of such a certificate, unless you have an external way of trusting it (for example, if you have installed it yourself on a machine and change check its content manually, or if someone you trust gave it to you).
(You may also be interested in this question about how an HTTPS server certificate is used.)
Generally the purpose of a certificate is to establish a trust chain: "I trust this 3rd party company, they trust you, therefore I can trust you." Self-signed certificate means you generated it yourself, and therefore I'm really not gaining trust in you. (These are great for testing, but not much else.) The other type is a trusted certificate, obtained by getting a reputable company to sell you one (like Verisign). It's a commodity market, so their prices are pretty consistent between companies. It does depend on the intended use and the scope of the certificate. (e.g. a certificate for signing an Android app is very different from a certificate used for validating https://www.example.com/.)
The "CA" or Certificate Authority is the company that issued the certificate. In the case of a trusted certificate, it's that company -- e.g. Verisign. In the case of a self-signed certificate, the CA is you -- you issued the certificate.
Self-signed certificates will cause some kind of "untrusted" alert in most browsers, asking you if you want to proceed and add an exception, etc. This does not mean the connection is any less secure though -- it is still over SSL.
Generally CA's charge a fee but there are some free ones around if you search.