During SSL handshake, the browser downloads any intermediate certificate from the host web server using the URL provided if needed. I believe browser comes with the pre-installed certificates from public CAs having only the public key of the root certificate.
1) When calling a https url using a standalone java program [https://xyz.com ..which is using Verisign certificate], i do not need to add that Certificate to any truststore since its root public is already available in jdk's cacerts truststore file. Is this correct statement?
2) When i run the same program from application server, it requires to add all the intermediate certificate to server truststore individually. Why this works in different way.
If the trust chain for the servers certificate is: root-intermediate#1-intermediate#2-server and the client (browser) has root as trusted CA in its CA store, it needs a way to verify the servers certificate by checking the complete chain up to the root. And because the client usually has no knowledge of the intermediate CAs the server needs to provide them.
Sometimes it seems to work w/o providing these intermediate CAs. First, the browsers usually cache the intermediate CAs they got and thus if intermediate#2 is the same as already seen by another server the verification will succeed, but only for the clients who visited the other server before :(
Another way is to provide a URL inside a certificate, where the issuer certificate can be downloaded, e.g. server could provide a link to the certificate for intermediate#2, intermediate#2 could provide a link to intermediate#1. In this case the client could download the missing certificates. But, this features is not universally adopted, e.g. some browsers might provide it but SSL libraries outside of the browsers usually don't.
Related
I have a business process which send messages to SAP via soap endpoint exposed by them.
I am using WCF-BasicHttp Send Adapter(In-Process).
As you can see below, earlier the url was http, now they have moved their system to cloud so now they have https endpoints.
I wanted to test this change from http->https, so I have modified the url to https, fill in the credentials for basic auth. it working fine in Test system without SSL Certificate, I need to make sure it wont cause any issue after moving to production system.
My Question is,
1/ Will it work in Production system too as its in TEST without SSL Certificate ?
2/ or Do I need to apply SSL for WCF-BasicHttp Adapter, if yes How can I do that ??
If you are moving to https URL, Certificate is must for SSL/TLS handshake. Many times, Certificate used by specific endpoint is signed by a third party Trusted Root CA e.g. Trustwave, DigiCert etc and these Root CA certs are already trusted on most of the systems. It’s possible in your test system, your endpoint certificate Root CA is already trusted and that’s why you did’t need to install the certificate. In order to check this, you can do following:
Browse your https service url in browser in chrome/IE
Look for Security/Lock sign to find it’s cert. Clicking the lock sign will open certificate.
Check the certificate root by going to Certification Path. You should see a chain of certificates in path. A cert can be by signed by just root CA Or by Intermediary CA first and then root CA. e.g.
—- Trustwave Root
—- Trustwave Intermediary
—- service cert
Or
—- Some Root
—- service cert
Check if Root CA is in your Trusted Root store of system. And Intermediary Cert (if applicable) is in Intermediary Cert Store. You can check this by opening certificate mmc snap-in using mmc command in Windows->Run and adding Certificates snap in of local computer.
If Root CA Cert and Intermediary Certs are not in your system store. SSL/TLS handshake will not complete successfully and BizTalk send port will not work.
If these are installed, you should be good. Otherwise install these certificates in local computer stores.
Another way to verify if endpoint certificate is trusted on a BizTalk system is to login with service account under which your send host is running and then browse the URL in IE. If you don’t get any Cert error, and URL opens such as wsdl URL, then you are good. If you get a cert error, this means end point certificate is not trusted and you need to install the certs as described above.
Some references:
View Certificate
Working with Certificates
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 have installed a ssl certificate via WHM on one of my domain. Site is working with https://xyz.com.
However it is not working with https://www.xyz.com. I have checked the certificate and it is for www version as well. After some research it appears to be incomplete chain issue. I had no idea how to resolve this. Please help.
A certificate can contain a special Authority Information Access extension (RFC-3280) with URL to issuer's certificate. Most browsers can use the AIA extension to download missing intermediate certificate to complete the certificate chain. But some clients (mobile browsers, OpenSSL) don't support this extension, so they report such certificate as untrusted.
You can solve the incomplete certificate chain issue manually by concatenating all certificates from the certificate to the trusted root certificate (exclusive, in this order), to prevent such issues. Note, the trusted root certificate should not be there, as it is already included in the system’s root certificate store.
You should be able to fetch intermediate certificates from the issuer and concat them together by yourself. I have written a script to automate the procedure, it loops over the AIA extension to produce output of correctly chained certificates. https://github.com/zakjan/cert-chain-resolver
I have a server with an SSL certificate and clients with SSL cetificates, all are signed by the same CA, and the CA is trusted on the server and clients as a root authority.
However none of the clients I have tried (iphone, chrome, explorer) will send the client certificate when the server requests it, even though they all verify the server certificate fine. They all claim not to have the certificate.
When I look at the client certificate in the certificate/profile/store they all claim it is verified and legit, and all the certificates verify fine using openssl etc.
Does an SSL client certificate need a specific name or other details so that client browsers will know when to use it? Kinda of like how a server certificate has to specify the exact domain as the name on the certificate?
The server is an apache2.2 server, but I don't think its a problem on the servers end.
Client certificates must have appropriate Key Usage and Extended Key Usage extensions set. What is "appropriate" in your case, I don't know for sure but the number of variants in Key Usage is small and you can check various values yourself.
You surely haven't forgot about the private key which should be accessible on the client side, have you?
There's a summary of the key usage and extended key usage extensions to use in this document:
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html
(Although it is for NSS, it should apply to other products.)
You could also check whether the list of accepted CAs sent by the server is configured properly. This can be seen using openssl s_client -connect the.host.name:443, for example.
When generating a self-signed certificate using keytool, can I use an IP address for the Common Name?
Once I generated the certificate, I exported it so I can install it in my clients/browsers. In Windows, I ran mmc.exe and added it as a Trusted Root Certificate Authority.
However, when I navigate to the IP address in my browser, it is still an untrusted connection. I ensured Tomcat had all the correct Connector settings.
Am I doing this correctly? do I need to be my own CA? How can I use SSL for development purposes? I'm still trying to understand SSL completely.
First question: if you'll be connecting by IP, then yes.
Second question: No, you don't install your self-signed certificate as CA, you just add exception when your browser warns you that it's self-signed.
You can set up CA — you generate root certificate first, install it in the client, and then generate CSR and then server certificate from it (see e.g. this), but for development purposes this is a complete waste of time.