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.
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 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.
I've been using an online SSL checker to check certificate validity for several sites.
One thing I noticed is that many websites have wildcard certificates - especially those hosted on common web hosting sites, such as goDaddy: *.onlinestore.godaddy.com
But those sites have custom domains and so when validating the SSL cert I can see an error where the hostname does not match the altnames listed in the certificate.
But all major browsers (tested chrome, FF, IE and Safari) still show the site as secure. Do the browsers not care that the domain names are not listed in the cert, and isn't that a security vulnerability?
Example: https://www.sslshopper.com/ssl-checker.html#hostname=www.cinnamonmotif.com
In case a wildcard certificate is installed on a domain, the browser only check the certificate validity and wildcard rule. As long as this rule is true the certificate id trusted and no warning appears.
If you look at the certificate that the browser resolved you'll see that it's different than sslshopper.com resolved.
When you go in a modern browser the client sends the TLS Server Name Indication extension, and the site notices that it's supposed to serve up the cinnamonmotif.com certificate.
SslShopper saw *.onlinestore.godaddy.com, which is certificate 0x6068c7475ab4ee2a from Go Daddy Secure Certificate Authority - G2.
With SNI the served up certificate is cinnamonmotif.com, certificate 0x3e0240d9425e8120 from Go Daddy Secure Certificate Authority - G2.
The fact that the browser saw a different certificate, which is a hostname match, is why the browser says it's a legitimate connection.
When I send a request a known site lik facebook, Google,... on https protocol, the certificates are appearing on browser via pedlock.
How the web site (facebook,google,..) certificate comes to my browser?
How my browser knows the certificate is valid? is asking the Certificate Authority company?
What means my computers trusted certificates (on Windows certmgr.msc)?
1. How the web site (facebook,google,..) certificate comes t y browser?
When your browser requests a website using the HTTPS protocol the transfer will start with a SSL/TLS handshake. During this handshake the server will submit the website certificate to your browser.
2. How my browser knows the certificate is valid? is asking the Certificate Authority company?
The website certificate is commonly provided by a certificate authority (CA). The CA has signed the website certificate with its own certificate - after it has verified the websites identity. Every browser has some certificates from trusted CAs pre-installed. These certificates are used to check if the submited website certificated is properly signed by the CA.
In addition the browser may use the Online Certificate Status Protocol (OSCP) to check if the website is still valid.
3. What meansmy computers trusted certificates (on Windows certmgr.msc)?
I guess this is a different topic. The CA certificates used for HTTPS connections are part of the browser (IE, FF, etc.) and no part of the operating system.
Additional notes
The way the browser displays a trusted HTTPS connection depends on the browser and of the type of the used certificate.
If you are interested in some details how the certificates are distributed, you may doa research to the topic of "Public-key infrastructure (PKI)"
I just installed an SSL on Plesk, and when I go to https://www.example.com in Chrome, I get the error below:
This CA Root Certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities Store.
Sort of defeats the purpose of having an SSL. Any idea how I can make this message go away?
I bought the SSL from GoDaddy, which I would expect to be a trusted authority.
This issue occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority (GoDaddy) provides a bundle of chained certificates that should be chained with the server certificate to address this issue of lack of trust. Unfortunately, GoDaddy does not provide any documentation on this front. You should have received two different certificates from GoDaddy, one for your server, and the bundle. Depending on your server, this is what the configuration would look like:
For Apache:
Specify each certificate in its own directive:
SSLCertificateFile /path/to/cert/www.example.com.crt
SSLCertificateChainFile /path/to/cert/bundle.crt
For Nginx, documented here:
Both certificates should be concatenated, first the server, then the bundle:
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
And then use www.example.com.chained.crt in your server ssl_certificate directive:
ssl_certificate www.example.com.chained.crt
GoDaddy is recognized on Windows operating systems, because the GoDaddy root certificate is pre-installed on Windows. But GoDaddy will not be automatically recognized in many contexts and would need to be manually configured by users (which is not a trivial task). IPhone, for example, will not trust GoDaddy certificates out of the box. You may consider getting certificate from established certificate authorities such as Verisgn or Thawte, but they will be more expensive.
#John: GoDaddy is a registrar/webhost, I believe their certificates are just reseller certs. You don't need to go expensive to get compatibility as #Jaro suggests. I've deployed several RapidSSL certificates that are recognized by Chrome/iOS and Safari/iOS without user intervention and are much cheaper than the higher-insurance certificates like Symantec/VeriSign.
The only way to make that message go away, is by buying a real certificate from a trusted authority.