Hi all
why apple has given link of entrust ssl ,is it necessary ?
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html
see at first note:
Note: To establish a TLS session with APNs, an Entrust Secure CA root certificate must be installed on the provider’s server. If the server is running Mac OS X, this root certificate is already in the keychain. On other systems, the certificate might not be available. You can download this certificate from the Entrust SSL Certificates website.
Yes, the certificate is necessary to establish a TLS session with APNs.
But you don't need to buy a certificate from Entrust. (I guess this was what you thought, because there are huge $xxx for a certificate boxes on the Entrust website)
The APNs uses a secure connection to a server that uses a certificate from Entrust. And this connection would fail when the CA root certificate wouldn't be installed on your computer. All "regular" certificates are only valid if the root certificate is known to your computer. And this is the file that they want you to download.
But most likely the Entrust Secure CA root cert is already installed. I used APNs from Ubuntu, and Arch Linux, and I installed nothing from Entrust. This is from my arch install, all necessary root ca certificates are already there:
[root#dellbook certs]# ls /etc/ssl/certs/Entrust*
/etc/ssl/certs/Entrust.net_Global_Secure_Personal_CA.pem
/etc/ssl/certs/Entrust.net_Global_Secure_Server_CA.pem
/etc/ssl/certs/Entrust.net_Premium_2048_Secure_Server_CA.pem
/etc/ssl/certs/Entrust.net_Secure_Personal_CA.pem
/etc/ssl/certs/Entrust.net_Secure_Server_CA.pem
/etc/ssl/certs/Entrust_Root_Certification_Authority.pem
It appears that you don't have to buy one of the Entrust certificates; you just have to download the certificate authority certificate (which is free) from their website. Apple should have made this more clear. I found the current link to this, which may not work forever, but for now here it is: https://www.entrustdatacard.com/pages/root-certificates-download
Related
There are two separate CA virtual machines (Windows Server 2012):
RootCA
SubCA - created/signed by RootCA
RootCA is off and offline (no network connectivity).
How to renew Microsoft SubCA?
SubCA is valid for more than a year now, but we want to plan ahead.
Root and Sub CAs are not connected to Windows domain, it is not for used for Active Directory.
SubCA is used to generate SSL certificates for out internal servers - Apache, Nginx, IIS, etc.
RootCA and SubCA certificates are trusted on Windows and Linux machines (both servers and workstations).
Is it necessary to add newly renewed SubCA certificate as trusted after renewinig it? Or it will be already trusted, but now it is just renewed?
The renewed SubCA will be trusted as it will be signed by the already trusted RootCA - that's how PKI works.
Never add the new SubCA certificate into your trust-store as it mustn't be explicitly trusted. It is only implicitly trusted because it's issuing CA (the Root in this case) is trusted. Remember that if you were to add it to the trust-store and you subsequently decided that the SubCA was compromised and therefore required revoking, you would have to manually remove it from all trust-stores - a laborious process.
Instead, you will need to give all subscribers this new SubCA certificate when you next renew their end-entity certificate so that they present the correct chain when relying parties connect (as required by the TLS protocol).
In the Windows world you can add it to the Intermediate CA store (not the Root CA store remember!) so that servers have it to hand when their end-entity certificate is renewed by the Sub CA. Windows will figure out which CA certificate to send when the end-entity certificate is renewed.
In the non-Windows world you have to read the documentation for the application to ascertain where the CA certificates should be installed. Quite often, they are appended to the file containing the end-entity certificate, but it can vary - so do check.
I have this weirdest problem. First off: I'm VERY new to this certificate thingy. I've done a fair amount of searches and reading up though.
The CA Cert that I install into the Trusted Root Certificate
Authorities store in my server automatically get removed/disappeared
as soon as a client web-browser try to connect to a web-site using an
SSL cert created with that CA cert.
DETAILS:
Windows Server 2008 R2 (development server).
I've created my own Certificate Authority Cert; which I use it to generate an SSL server cert (to install on my IIS 7 Server) and a client cert (for use at my local PC to connect to the WCF Webservice on the development server which is set to Require SSL and Require Client Cert).
I installed the CA Cert into the Trusted Root on both Server and local PC.
Installed the SSL server cert into the IIS7 for that particular site and did the https binding to port 443.
As soon as I launch my browser to access that site with HTTPS, the CA
cert in automatically removed on the server (from the Trusted Root
Certificate Authorities store). and my local PC browser will report
an error 403.
This is driving me nuts... anyone knows what is happening?
Apparently, after a lot of running around, it is due to too many of the same certs in many stores.
I open the MMC.exe > Add/Remove SnapIns > Certificates
Notice there are 3 types there (My User Account, Service Account & Computer Account).
Open up My User and Computer Account, go through all the stores for each one and DELETE all of the CA cert with the same name. Then add the CA cert in either My User Account or Computer Account, depending on how you access the certs (in the event of the cert being used programatically, install it in the Computer Account, [Trusted Root Certificate Authorities].
Just 1 place, then the problem will dissappear.
I'm not clear about the authorization of certificate: a website has been associated with a certificate, say https://test.mysite.com. Do I have to install the certificate on my computer before access this url?
Another question is: every certificate is issued by a CA. If I have trusted a CA before by "installing" a cerficiate, will I trust the all the following certificates issued by the same CA?
Thanks!
It depends on the library or browser you are using to access to the URL but, if the certificate is issued by a trusted CA (one that your library or browser already trusts), the web site's certificate does not need to be installed before accessing the site.
If the CA is not trusted, there are two options. One is to trust the certificate. Browsing to the page will usually open a dialog where the user can choose to trust the certificate, for example. The second is to add the CA to the list of trusted CAs. On Windows, this is done by adding the CA's certificate to the "Trusted Root Authorities" certificate store. The latter case means any other certificate issued by the CA will also be trusted.
I am looking for a open source implementations of certificate authority software, where I want to generate Root CA certificate and install it on my client machines, and generate SSL certificates for my local websites and install it on the webservers.
I believe, if I install root CA certificate on my client machines, the browsers wouldn't be showing me the certificate errors ... is that right ??
I found this wiki node http://en.wikipedia.org/wiki/Certificate_authority and they have a list of open source softwares: EJBCA, OpenCA, OpenSSL, gnoMint, DogTag, XCA, r509.
I am not sure which one will a be good choice for me, if anyone has any experience with it please share with us.
You are right regarding browser complaining about certificate. If you install Root CA certificate into your trusted certificate store and server certificates will be signed by this Root CA, you won't see error messages any more.
I think for your purposes OpenSSL is what you need. You should be able to create all necessary certificates in just several commands.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.