Can I use a certificate issued by RapidSSL for an OCS Edge Server installation?
Your CA has to be one of those that is trusted by a default installation of Windows in order to be used for OCS federation purposes. I don't see RapidSSL in the list on my W2k8 box.
Related
I have a web page with apache, and it is hosted only in localhost, but all devices that are connected to my network can be entered using my ipv4 (192.168.1.x), I have installed a certificate using openssl, but the certificate is only valid For my pc where I am hosting the site, if I try to enter with another device it tells me that it is not valid.
That's expected since the Certificate Authority (who emitted your certificate) is not trusted by the browsers. You'd need to install your CA certificate in your clients in order to make them trust the certificates emitted by that CA.
If you own a valid domain, you may buy a certificate for it from a trusted CA, or even emit a certificate using Let's Encrypt, which emits free SSL certificates that are trusted by all major browsers currently. Remember that this won't work neither for invalid/local domains or domains that you don't own.
I read about server authentication over web and got to know that issuer Root CA should be imported into Trusted Root CA on both server and client machines for mutual authentication.
Now let's say it is banking application.
The user connects to the bank server for the first time:
Server returns server certificate to validate itself to client.
Client gets the certificate and validate with trusted Root CA authority which has signed this server certificate earlier.
Client sends its certificate and server validate with trusted Root CA
authority which has signed this client certificate earlier.
Now communication starts.
In Step 3 I understand that the trusted Root CA authority is installed on the server when the server gets deployed.
However, in Step 2 when the client machine connects for the first time (and can dynamic connected from any machine), how does the Root CA authority got installed on the client machine?
Root CA certificates are usually preinstalled in operating system and software (when software use its own trust store). Administrators may use their tools to deploy additional roots (which are not common, for example, organization's private roots).
When I send a request a known site lik facebook, Google,... on https protocol, the certificates are appearing on browser via pedlock.
How the web site (facebook,google,..) certificate comes to my browser?
How my browser knows the certificate is valid? is asking the Certificate Authority company?
What means my computers trusted certificates (on Windows certmgr.msc)?
1. How the web site (facebook,google,..) certificate comes t y browser?
When your browser requests a website using the HTTPS protocol the transfer will start with a SSL/TLS handshake. During this handshake the server will submit the website certificate to your browser.
2. How my browser knows the certificate is valid? is asking the Certificate Authority company?
The website certificate is commonly provided by a certificate authority (CA). The CA has signed the website certificate with its own certificate - after it has verified the websites identity. Every browser has some certificates from trusted CAs pre-installed. These certificates are used to check if the submited website certificated is properly signed by the CA.
In addition the browser may use the Online Certificate Status Protocol (OSCP) to check if the website is still valid.
3. What meansmy computers trusted certificates (on Windows certmgr.msc)?
I guess this is a different topic. The CA certificates used for HTTPS connections are part of the browser (IE, FF, etc.) and no part of the operating system.
Additional notes
The way the browser displays a trusted HTTPS connection depends on the browser and of the type of the used certificate.
If you are interested in some details how the certificates are distributed, you may doa research to the topic of "Public-key infrastructure (PKI)"
I have a W2K8 R2 SP1 server hosting an SSL web site requiring client certificate. We have a root certificate (self signed), saved in local machine trusted CA store. On client, browser asks for a client certificate and it works fine.
Now, we have another root certificate that is also saved in local machine trusted CA store. Problem is that the browser does not offer to choose client certificate issued by this root CA.
Reason why browser does not prompt is that server is configured (default option) to return a list of trusted root CA to the client to help it limit the list of client certificates to choose from. If we configure the server so that it does not provide this list (HKLM/system/currentcontrolset/control/securityproviders/schannel/sendtrustedissuerlist=0), the browser has not clue and displays all client certificates and then it works fine.
We had a problem like this in the past because the list of trusted CA was too long and thus was truncated when returned to the client but it's not the case here, only 8 trusted CAs are returned.
Also, if I register this new root CA on another (very similar) server, there it works fine, returned trusted list contains the new CA.
I'm really out of clue why this specific server refuses to return my root CA in the list during SSL negotiation, can someone help please ???
Not sure if this helps you or someone else but according to Microsoft and their Windows Server 2012 documentation your problem seems to be related to this:
"If the Trusted Root Certifictation Authorities store that was used contains a mix of Root (self-signed) and certification authority (CA) Issuer certificates, only the CA Issuer certificates will be sent to the server by default".
Keep on mind that you may use different store for "Certificate Trust List" (CTL). "Client Authentication Issuer" store is being checked/used first (by default on Windows Server 2012) and then if empty "Trusted Root Certifictation Authorities" store.
If you were on 2012, you could have manually configured CTL store, but I don't think that option was present on 2008 R2 (though I might be mistaken).
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.