I'm wondering why we need SSL certificate ? Because the moment we generate the keystore, it does the same functionality. It gives SSL platform.
May I know please why we need certificate and if it really needs then how it works (Certificate merged with keystore) when a third party sends a request to access web-server's website ?
To use the SSL certificate in a web server, you configure your web server software (Apache, NGINX, etc...) to read the certificate. Tutorials on this topic abound; here is a sample set of instructions from DigiCert, who sells SSL certificates: https://www.digicert.com/ssl-certificate-installation-ubuntu-server-with-apache2.htm
Related
It must be something really simple but right now I am not getting anywhere with this (I am not a network geek but a programmer).
We are trying to secure web services created between our server and a vendor. Our vendor is asking to send them the public key for an SSL certificate to secure requests and responses in our web services.
What I did
I forwarded the following to our hosting provider but they only provide SSL certificate for websites and didn't give any clear clue to what to do next.
Create a Certificate Signing Request (CSR) with any CN
Have CSR signed from CA
Merge the signed cert file with the CSR to create the actual
certificate
Extract the public and private certificates
What I need
All I need simple set of instructions to what I should do or where can I get/purchase this certificate.
Thanks,
I am trying to activate HTTPS for my domain name. Chrome recognizes the SSL certificate when i go to https://www.example.com, but I get the error and it says that my SSL is not trusted. What do I need to do to get my SSL certificate to be trusted?
Instead of using a self-signed certificate, get one from a certificate provider. I'd recommend you looking at LetsEncrypt because they have a good automated support for being able to renew certificates automatically.
I have installed SSL Certificate manually that I had brought from Godadday. It installed successfully but it shows self signed certificate which is not trusted or displays cross on https.
What is the solution ?
It is showing because it does not recognized the certificate that you get from Godaddy.
The CSR certificate has to upload on your site and make changes on apache config file.
Make sure your CSR file should not match with the private key that you submitted to verify your site.
Installing a SSL certificate requires some server administration knowhow, especially updating web server configuration.
DigitalOcean has a great tutorial on how to install a SSL certificate from GoDaddy: https://www.digitalocean.com/community/tutorials/how-to-install-an-ssl-certificate-from-a-commercial-certificate-authority#example-ca-2-godaddy
Maybe it helps.
To check if you installed it correctly, you can use Qualys SSL Server Test at https://www.ssllabs.com/ssltest/index.html
We are consuming xml from different datasources. Some are http and some are https. HTTPS with Verisign certificates are working without any issues. However, URLs with Deutsche Telekom Root certificate is not working. The web sphere application server is having the default root certificate which was generated while creating a WAS profile. Do I have to add any other special certificate to make Deutsche Telekom Root certificate work ? Any kind of help is much appreciated.
I don't think I know enough about your setup yet. So by default WebSphere creates it's own root certificate, nothing about it would trust a Verisign certificate. So I wonder about what you are using to make the https connection? It could be something that manages to bypass the WebSphere socket factories and you are actually using the JRE's default, and the cacerts file for trust. Verisign certs are in the cacerts file there are no Deutsche Telekom as far as I can tell.
Or was a Verisign certificate added to your WebSphere truststore at some time?
Typically you have establish trust to make WebSphere trust another server. Retrieving a certificate from a port is a good way to do that.
Alaine
Please, post the WAS version you use.
The reason you cannot setup the connection to ssl port is that WAS doesn't trust to the ssl certificate of the remote host.
You have to add the whole certificate chain of the remote host to the WAS truststore.
You can find the example of how to add the certificate by following link https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=8&cad=rja&uact=8&ved=0CE0QFjAHahUKEwiRy4zsztzGAhXCfHIKHVq-BfM&url=http%3A%2F%2Fwww.webspheretools.com%2Fsites%2Fwebspheretools.nsf%2Fdocs%2FBasic%2520SSL%2520terminalogy%2520and%2520Tips%2520for%2520WebSphere%2520Application%2520Server.Default%2520passwords%2520for%2520SSL%2520keyfile%2520and%2520Truststore.&ei=DwymVdGHDcL5yQPa_JaYDw&usg=AFQjCNE42W06AILWb99iYWiUp7EcbT92iw&sig2=KKYyvAsFET1Ae0fOLSl8zA&bvm=bv.97949915,d.bGQ
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.