Here is my site https://sample.in I placed the another webapplicaton in the same domain,its home page url is
http://www.sample.in:8080/anotherapplication-name/login.jsp
the above url is login page,when enter the credentials its navigating to main site url like
https://sample.in/anotherapplication-name/NavigationFrameset.jsp
In the browser i am getting the following message
Your connection is not private
Attackers might be trying to steal your information from www.ilovesalesevents.in (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
Please any help!!!!!!!
Your cert does not match your domain name.
You're not clear which application is "another", but the domain names [www.]sample.in resolve to 192.254.254.73
which is using a cert that was issued to [www.]vb.in -- and also expired 3 months ago (Feb 18). [www.]vb.in doesn't exist according to all authoritative DNS servers except one I couldn't reach,
and my ISPs have (presumably stale) records mapping these names to 92.242.140.21 and 198.105.244.11 which both don't respond at all.
For most uses of SSL/TLS including HTTPS, the server cert must contain the domain name(s) "of" the server, or more exactly the domain name(s) used to reach the server. If you want to use domain name(s) [www.]sample.in, you must get a certificate for that domain name(s).
Related
Is it possible to send a HTTPS POST request to a server that you only have the public key to (and not the whole certificate - obviously not talking about the private key here)?
Here is my setup. Both Server and client are developed and controlled by me.
HTTPS Server
has untrusted root certificate for https (from ZeroSSL, 90 days expiration)
Java Client (on github - open source)
has to send a file over an https connection
the app is downloaded by random people with varying technical knowledge (manual file imports for java key storage - as I've seen them in many stackoverfow posts - are not an option)
the client app runns more than 90 days (hardcoding certificates is not an option, but the server's public key should stay the same after a renewal, which would make hardcoding this one in possible)
I want this to be as secure as possible (trusting all certificates is also not an option)
Now i've seen one person talk about "pinning the server's public key" in a comment. Does anyone know more about how to do that? It sounds exactly like the thing I'm looking for.
UPDATE 1: This site https://whatsmychaincert.com/ fixed at least a problem I had with my certificate not being installed properly, where firefox was fine with it, but ZeroSSL told me it wasn't properly installed. What that site did was to create a chained.crt file that basically consists out of the content from certificate.crt and the ca_bundle.crt combined (copypasted one and then the other file content with a line break in between). This file i then put instead of the certificate file in the node-red settings.js.
/** Option 1: static object */
https: {
key: require("fs").readFileSync('private.key'),
cert: require("fs").readFileSync('chained.crt')
},
It made things better but let's see if it also fixed my main problem...
I am getting a warning :
not secured for Chrome but in IE it is working fine
site url :-https://10.71.8.165:8443/NextGene/
Detailed warning:
Your connection is not private
Attackers might be trying to steal your information from 10.71.8.165 (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
Help improve Safe Browsing by sending some system information and page content to Google. Privacy policy
This server could not prove that it is 10.71.8.165; its security certificate does not specify Subject Alternative Names. This may be caused by a misconfiguration or an attacker intercepting your connection.
Proceed to 10.71.8.165 (unsafe)
I have tried to give SAN same as of ip 10.71.8.165, but still facing same issue.
please, suggest any solution
If the IP address has a DNS entry that matches the certificate's subject and, more importantly, is in the certificate's list of Subject Alternative Names (SANs), use that. If your organization does not have a DNS entry for the IP address, add a DNS entry that maps to that IP address and is contained in the certificate's list of SANs.
Thank you
Yes it is working for chrome browser but still my site is not working for mozilla.
mozilla version is :70.0
error:-Warning: Potential Security Risk Ahead
Someone could be trying to impersonate the site and you should not continue.
Websites prove their identity via certificates. Firefox does not trust iims.jci.com:8443 because its certificate issuer is unknown, the certificate is self-signed, or the server is not sending the correct intermediate certificates.
Error code: SEC_ERROR_UNKNOWN_ISSUER
I am quite new to working with certificates and security, so pardon me if this is a no-brainer to others. I have followed this guide to set up my Grails application to run on HTTPS with self-signed certificates.
I am trying to establish 2-way SSL with another HTTPS network (a Nifi standalone instance) running on the same machine. I can get the Nifi instance to talk to Grails over HTTPS, but I am having issues with Grails talking to Nifi (specifically to a ListenHTTP processor).
I was hoping someone could advise how to use certificate authentication in Grails when posting over HTTPS.
Nifi uses certificate authentication; however per the above guide Grails only specifies a single keystore (for receiving requests?) so I'm a bit thrown off. I can successfully CURL to Nifi's REST API by specifying the --cert and --key properties, but since the final product will be a WAR on a client machine I want to set this up the 'right way', and I believe leaving those files on the client machine is a really big no-no for security.
During early development RestBuilder was sufficient for 2-way comms over HTTP, however, I am unable to find any mention of using it with certificate authentication (only basic authentication is covered in the documentation?).
HTTPBuilder shows up a lot when I looked for alternatives, however looking at the relevant documentation (line 139 'certificate()') it states that it takes a whole keystore JKS and password. I think this is close but not quite what I am looking for considering I only have one keystore; I am open to correction here.
Please note that I will be unavailable to respond until at least the day after this question was posted.
When making an outgoing HTTPS connection, if the remote endpoint (in this case Apache NiFi) requires client certificate authentication, the originating endpoint (Grails) will attempt to provide a certificate. The certificate that Grails is using to identify itself as a service is fine to use in this scenario, provided:
The certificate either does not have the ExtendedKeyUsage extension set, or if it is set, both ServerAuth and ClientAuth values are present. If ClientAuth is missing, the system will not allow this certificate to be used for client authentication, which is the necessary role in this exchange.
The certificate has a valid SubjectAlternativeName value which matches the hostname it is running on. RFC 6125 prescribes that SAN values should be used for certificate identity rather than Distinguished Name (DN) and Common Name (CN). So if the Grails app is running on https://grails.example.com, the SAN must contain values for grails.example.com or *.example.com.
The certificate must be imported into NiFi's truststore in order to allow NiFi to authenticate a presenter of this certificate.
NiFi must have ACL permissions in place for this "user". This can be done through the UI or by modifying the conf/authorizers.xml file before starting NiFi for the first time. See NiFi Admin Guide - Authorizers Configuration for more information.
Your concern for leaving the cert.pem and key.key files on the client machine is understandable, but the sensitive information contained therein is the same data that's in your keystore. At some point, the private key must be accessible by the Grails app in order to perform HTTPS processes, so having it in the keystore is functionally equivalent (you don't mention having a password on the *.key file, but obviously you should have a password on the keystore).
The question is, How to solve "The certificate is not valid and cannot be used to verify the identity of this website" error?.
Here are the details:
I have a signed applet that has been working fine, until I updated Java to 8u25 (1.8.0_25-b18). Now, the application shows an alert message "Do you want to continue? The connection to this website is untrusted". There is a note in this message too, "The certificate is not valid and cannot be used to verify the identity of this website".
The applet is loaded without problems. But when the user tries to use a specific function of that application, the warning message is displayed.
I've checked the java console when this happens, and this warning message is displayed right after these lines:
security: Obtain certificate collection in SSL Root CA certificate store
security: Invalid certificate from HTTPS server
network: Cache entry not found [url: https://sub.domain.net:9876, version: null]
The application is downloaded from a different domain, say "https://app.domain.net/.....", so no jars are downloaded from "https://sub.domain.net:9876", but the applet connects to "https://sub.domain.net:9876" to send/receive data.
The applet is signed correctly, and so far, it meets all the security requirements according to Java. This issue seems to happen when the application tries to connect internally with an HTTPS url like https://sub.domain.net:9876. That sites' SSL certificate is valid, issued by GoDaddy and has not expired.
Again, this started to happen after updating my JRE to 8u25. I've tested adding the offending URL to Java security exception list, with no success.
Here are a few screenshot of this problem:
This is the warning message displayed:
Edit 10/18/2014:
Question posted in "Oracle Community" too, to increase answer options:
Question in Oracle Community.
Edit 10/21/2014:
I noticed this: When I click the link "More Information" displayed in the "Security Warning" dialog, the reason displayed says:
The application is being downloaded from a site other than the one
specified by the security certificate.
Downloading from "sub.domain.net"
Expecting "*.DOMAIN.NET"
This message says the application is BEING DOWNLOADED FROM "sub.domain.com", and that is false. The application (applet) is already downloaded, and it is only using that domain in an internal HTTPS request, to get/send business data, not to download additional Jars, JNLPs, etc.
I found how to solve this issue, and thanks to Steffen Ullrich for a valid proposal.
This is related to the certificate's Common Name (CN) value. In my case, that value was *.DOMAIN.NET, and to change it to *.domain.net, all we had to do was a procedure called "Domain Transfer". This means, to change the CN to *.REKEY.DOMAIN.NET, and then to change it again to *.domain.net. We could not change it to *.domain.net directly because the certificate provider says *.DOMAIN.NET and *.domain.net are the same.
Now, this issue happened only with Java 7.71 and Java 8.25. Previous version of Java 7 and 8 don't have this issue (SSL certificate restrictions for CN in a different casing).
Anyway, this solved the issue, and now we receive a gentle information message about the domain:
If you trust the certificate and the website you are accessing, hit Continue to get past this message.
However, unless you ABSOLUTELY trust that website, this is a red-flag warning that you may not be accessing the page you think you are, and there may be a serious security risk. That's why it warns you. A "wildcard certificate", if that is indeed possible, would be a Bad Idea unless it restricts itself to a very specific and limited set of domains.
I doubt this is case-sensitive.
I've been trying to adopt myself and my applet to the new security constraints imposed in Java 7.
My applet is self signed and as such, it was automatically blocked. After adding the site to the exception list in the java configuration console I managed accessing it but not without having to see that annoying message shouting at me that the signer is UNKNOWN, requiring me to approve running the applet.
This one is really annoying as it requires my approval each time I try to load the applet...not storing my previous approval...
so, I found this document which should have solved all my problems as the distribution of my applet is within a known community. I followed all the guidelines, created the certificate and entered it into the store that is used by the JRE (I also see that certificate from the configuration console) but the annoying approval message keeps popping and saying that the signer is still UNKNOWN...
any idea, what I'm missing? it looks like the addition of the certificate into my store had no impact on the flow whatsoever...
thanks in advance.
GBa.
Unfortunately mentioned certificate fields are not provided so maybe my guess is wrong but I would suggest that you create a certificate where the Common Name in the Subject field matches the signing authority address. There are three ways to have a match and eventually avoid the warning:
1. The host name (in the address bar) exactly matches the Common Name in the certificate's Subject.
2. The host name matches a wildcard common name. For example, www.example.com matches the common name *.example.com.
3. The host name is listed in the Subject Alternative Name field.
The most common form of SSL name matching is for the SSL client to compare the server name it connected to with the common name in the server's certificate.
If an SSL certificate has a Subject Alternative Name (SAN) field, then SSL clients are supposed to ignore the common name value and seek a match in the SAN list.
Well, I finally found the problem...
It turns out that once I cloned the trusted.certs (deployment.user.security.trusted.certs) file into trusted.cacerts (deployment.user.security.trusted.cacerts) file, everything started working...
I do not understand what the difference is between the two stores, futhermore, in the link that I added in the question (this), it talks about the certs file for individual usage and so... it made sense to me that it should work... however, it turns out that Java thinks differently :-)
anyways... this is the answer.
thanks everyone for your collaboration,
GBa.