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.
Related
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
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'm using jelastic to run my application. When I run the sslchecker on the site, I get an error about You may need to install an Intermediate/chain certificate to link it to a trusted root certificate.
In the Jelastic Custom SSL configuration, I have added the intermediate certificate. I have 2 of those. How can I install both. Right now There is only a option of installing one intermediate certificate. But according to Comodo's installation instuctions I need to install both the certificates. How can I do that.
Usually root certificate is not needed because it already exists in all web browsers. But sometimes, in case when web-browser is not used for communication, the root certificate should be present. For example when java application communicates with another application or java-client using trusted connection.
In this case instead of intermediate certificate should be uploaded chain of intermediate+root certs.
It is very easy to merge 2 or more certs. Open two intermediate certs using text editor. Copy root cert and past it to end of intermediate as on screenshot.
After changing ssl certificate authority from Thawte to DigiCert.
SSL certificate installation issue.
After installing new DigiCert ssl certificate in our server. It is still referring to old Thawte ssl certificate even though we removed old certificate from the server.
Looks like you have another vhost file using the old certificate , please remove that from your . Also make sure you properly restart apache after adding the new certificate .
To check your installation you can use the tool below
Thawte certificate checker
To see what certificate you are using, you can use the following tool Tool
This tool will allow you to check what certificate is installed on your server. Then, you can use the utility tool utility tool
You will be able to see all of the certs from your local machine or server. If you don't see the certificate there, you can import your certificate with that tool. If the utility tool mentions that your private key doesn't match, you will have to recreate the CSR with the utility tool and you will have to reissue your cert. If you reissue your cert, you will not invalidate the original request.
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.