I'm reading tutorial http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html
There is a part "Install the CA Certificate on the Web Server":
<VirtualHost _default_:443>
...
SSLCACertificateFile /var/www/conf/ssl.crt/ca.crt
...
</VirtualHost>
I wonder why I have to add on www server CA certificate and not generated client or server signed by CA certificate. CA certificate looks like it is universal and widely available for everyone, so somebody could sign in CA own csr and try to login ony my server.
Regards
A client certificate is used to identify a specific client. Usually you have multiple clients and each of them got their own certificate from your CA. While you could give the server all client certificates you ever generated (I don't know if this is possible with apache), it is much easier to give the server just the CA which issued these certificates and let the server verify, that the client certificate was issued by this CA.
Related
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.
I am not very familiar with the SSL Certificates and how they work.
However I succeed to install a SSL Certificate via cPanel of my shared hosting.
Please checkout this page: https://www.sportsdirect.bg/customer/account/create/
As you can see there is a problem with the certificate.
The padlock in the browser URL address is not green. Can you please tell me what can be the reason for this and how I can fix it ?
Off topic for this site.
Your web server is not properly configured to deliver the full certificate chain, see https://serverfault.com/questions/633247/ssl-error-on-mobile-devices .
Check your SSL Labs report and you will see Chain Issues: Incomplete. Your intermediate certificate:
RapidSSL SHA256 CA - G3
Fingerprint: 0e34141846e7423d37f20dc0ab06c9bbd843dc24
RSA 2048 bits (e 65537) / SHA256withRSA
... is not in your server's trust store and is not being served. Take a look at How to install an Intermediate CA cert in Apache.
The question is very clear but I did not find any useful tutorial online. So I wish I could have some luck here.
Basically, I want to build a client certificate authentication with Apache. I configured the conf file for Apache for the site I am hosting. The conf I put is here:
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /etc/apache2/ssl/client.crt
However I have no idea how to generate the certificate and key file for the client. And also, what file should I put on the SSLCACertificateFile in the Apache server configurations?
Does the server simply compare the certificate file sent from client with the certificate file on the server? What exactly the client certificate authentication is doing ?
You'll find instructions on how to create a CA cert and certs signed by this CA cert here:
http://pages.cs.wisc.edu/~zmiller/ca-howto/
Things go like this:
you setup your root CA key and cert
client generates his private key and certificate request
they send you the certificate request
you generate the certificate using the certificate request, your root CA cert and root CA key
you return the certificate to the client
You can then check that the client presents a certificate which is "signed" by the CA.
It is important to understand SSLVerifyClient and the other directives.
From Practical Issues with TLS Client Certificate
Authentication (page 3):
The default value none of SSLVerifyClient does
not require CCA; therefore the server will not include a
CertificateRequest message in the TLS handshake.
The value require will require CCA, and thus the
CertificateRequest message will be included in the
handshake. If the client does not provide any certificate in
the client’s Certificate message or mod_ssl fails to
verify the certificate provided, the TLS handshake will be
aborted and a fatal TLS alert message will be sent to the
client.
The value optional is the same as require, but
an empty client’s Certificate message will be tolerated.
The last possible value optional_no_ca is the same as
optional, but in addition it allows a client’s certificate to be
submitted that does not chain up to the CA trusted by the server
(because of a bug in OpenSSL [6] not yet valid or expired
non-self-signed client certificates will also be accepted).
The
value optional_no_ca can be used to perform certificate
verification at an application level or to implement PKI-less
public-key authentication that uses X.509 certificates as a
public-key transport.
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.
I just installed an SSL on Plesk, and when I go to https://www.example.com in Chrome, I get the error below:
This CA Root Certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities Store.
Sort of defeats the purpose of having an SSL. Any idea how I can make this message go away?
I bought the SSL from GoDaddy, which I would expect to be a trusted authority.
This issue occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority (GoDaddy) provides a bundle of chained certificates that should be chained with the server certificate to address this issue of lack of trust. Unfortunately, GoDaddy does not provide any documentation on this front. You should have received two different certificates from GoDaddy, one for your server, and the bundle. Depending on your server, this is what the configuration would look like:
For Apache:
Specify each certificate in its own directive:
SSLCertificateFile /path/to/cert/www.example.com.crt
SSLCertificateChainFile /path/to/cert/bundle.crt
For Nginx, documented here:
Both certificates should be concatenated, first the server, then the bundle:
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
And then use www.example.com.chained.crt in your server ssl_certificate directive:
ssl_certificate www.example.com.chained.crt
GoDaddy is recognized on Windows operating systems, because the GoDaddy root certificate is pre-installed on Windows. But GoDaddy will not be automatically recognized in many contexts and would need to be manually configured by users (which is not a trivial task). IPhone, for example, will not trust GoDaddy certificates out of the box. You may consider getting certificate from established certificate authorities such as Verisgn or Thawte, but they will be more expensive.
#John: GoDaddy is a registrar/webhost, I believe their certificates are just reseller certs. You don't need to go expensive to get compatibility as #Jaro suggests. I've deployed several RapidSSL certificates that are recognized by Chrome/iOS and Safari/iOS without user intervention and are much cheaper than the higher-insurance certificates like Symantec/VeriSign.
The only way to make that message go away, is by buying a real certificate from a trusted authority.