I have the company CA signed certificate, intermediate and server certificate in the identity store ( .jks) but still the browser says , cannot be verified by a trusted authority error. Using weblogic -10.3.1 from the weblogic logs i also notice this -
Invalid/unknown SSL header was received from peer x.y.z.12 during SSL handshake
But when I install the root and intermediate certificates into certmgr.msc then when i access the url again in a new window it has no error on the browser and also no error log in the weblogic server.
What could be wrong ?
Global CA's have their root and intermediates recognised by all the modern browsers. However when browser encounter s a certificate whose intermediate and roots aka chain certificates & ca certificates are not a part of its trust store so it fails to chain the leaf certificate to its issuer. So in order to mitigate thi, the roots and intermediates of the company ca must be added so that the browser can verify the complete chain.
Agreed .but thats how the trust works. The company issues ca certificate is known only to your organization but browsers are accessed globally and if you want make the certificate trusted in all the browsers then either you switch to public ca issued certificates or get your root certificate cross signed by a global ca root.
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.
When a TLS handshake takes place, the server sends in his ServerHello message, his digital certificate. This digital certificate is digitally signed by a intermediate CA named A and CA A also has a certificate which is signed by CA named root whose certificate is self signed, thus forming a certificate chain. The client then has to establish a trust, validating the server certificate. To perform that validation the client has to validate the entire chain correct?
Must the client have in a truststore all the certificates (A and Root) or the client will download them?
The client usually has only the root CA in the local trust store. The leaf certificate and the intermediate certificate leading to the root CA need to be provided by the server. The intermediate certificates are usually send in addition to the leaf certificate within the TLS handshake.
But it is a typical misconfiguration to only have the leaf certificate send by the server. In this case the certificate validation will fail unless the client has already knowledge of the intermediate certificates or can obtain these somehow. Since often the same intermediate certificates are used, some browsers like Firefox will cache the intermediate certificates they'll got when communicating with server A and fill these in when a broken server B is not sending the required intermediate certificates. Other browsers (like Google Chrome) will try to download the missing intermediate certificates from the internet. Most simpler clients (i.e. apps written in Python, Java ... or curl) will instead just fail with a certificate validation error.
I'm creating a Certificate Authority with openssl, and signing my server & client certificate with it (they both are the same).
Installing CA as a Trusted Root CA and Intermediate CA, server certificate - as a Personal one.
Adding server certificate in IIS6, adding bindings - and getting the right https connection via browser on server side.
But on the client side -
Installing CA as a Trusted Root CA and Intermediate CA, client certificate as Personal, server certificate as External.
Checking all the certificates - they are in a working state, CA is connected to client, everything looks normal.
Trying to get via Chrome - I'm getting the connection, but it is unsecured (can't connect to https). (But I still can connect Chrome, and use all the requests in Google Rest Client.)
In IE I'm getting ERR_TUNNEL_CONNECTION_FAILED.
What am I doing wrong here?
SOLVED. Had the same serial_number for both client and server certificates
SOLVED. Had the same serial_number for both client and server certificates
I have simple app runing on jboss server. I have following certificates:
Self Signed Root CA, intermediate CA 1 (signed by root), intermediate CA 2 (signed by root), .pfx certificate for my webpage. I had created a keystore with my .pfx certificate and added it to correct folder in jboss and modified http connection in server.xml file. Anyway when i acccess webpage i see warning triangle that CA is unknown. My question is how shoudl i configure jboss to make warning disappear? Soudl i add it to the trustore? or only way is to add it to Windows/web browser root store?
The browser's warning page appears because the self-signed certificate is not locally trusted. There is nothing that can be done on the server end to hide this warning.
You must put the certificate in the browser's trust store, or get a certificate from a certificate authority that is already trusted.
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.