I have a problem accessing my site (on https) with IEMobile 9 (WP 7.5).
It says it's got problem with the certificate, as if it wasn't valid. Everything works on any other browser or platform I tested (android (several phones and a galaxy tab with stock browser, firefox, opera, dolphin), iOS (iphone and ipad with safari and chrome), an old nokia with symbian, windows 7, linux and mac).
To try to solve this I saved the certificate (.cer) on the server and accessed it from the phone browser. It always complained except when I accessed it through the server IP (192.168.xx.xx). At that point it (said it) installed correctly the certificate. If then I try to access the index.html still using the IP all works fine and it doesn't complain about the certificate. If, though, I try to access the index using the actual URL (blah.myblah.com), it complains again about the certificate, as if it wasn't installed!
It isn't a problem of DNS, cause that's up and serving the right ip, and the phone is correctly setup to use it.
The certificate is signed by geotrust/rapidssl for *.myblah.com.
That's normal. certificates are issued to a particular host+domain name. Basically, SSL's validation code will have something like
if (requested host name != certificate issued hostname) {
issue security alert
}
so you're doing
if (192.168.xx.xx != example.com) {
and get the security warning.
I have had issues with certificates related to how some HTTP over TLS implementations look for SubjectAltName(SAN). RFC2818 states that, if the hostname is a DNS entry, implementations must check the hostname against the subjectAltName extension array looking for a DNS entry that matches the host. In case there's no subjectAltName CommonName is used.
If the hostname is an IP, the certificate must contain a subjectAltName IP entry matching the IP.
Also note that wildcard certificates are being discouraged by the newer RFC6125, so MAYBE windows phone is already enforcing this, although I might be wrong.
My first step would be to check the SAN portion of the certificate and make sure it has a DNS entry matching the your site's host.
Related
I'm fairly new to the whole certificate shebang and not a versed Linux admin.
In our company, we run a Windows domain, but we also have some CentOS servers for different services.
On one of said servers we have our ticket system, which is browser based. I want to certify it with a certificate, signed by our Windows root CA, but no matter what I do, the certificate is shown as invalid in the browser.
Funny enough, both certificates in the chain (CA -> server) are shown as valid.
I already did the following:
start certificate process from scratch
tried different certificate formats (.cer, .pem)
verified server cert with root cert
checked validity with openssl (OK)
checked SSL connection with openssl, no issues
added root cert to Linux server trusted CA store
recreated cert chain (of 2)
restarted Apache over and over
reset browser cache
tried different browser
checked DNS entries
checked, if root CA is trusted in Windows (it is)
manually installed server cert in my browser
Both the server cert and the root cert show up as valid in the browser, with the correct relation.
I'm completely lost here. Is there some key step I forgot and not one of the ~30 guides I read forgot to mention?
Any help is greatly appreciated
Your question is missing some information:
Did you check the SSL connection from outside the server?
Did you verify the RootCA cert is inside the cert-store of the server (sometimes it is rejected without error messages)?
I would check the reason for rejecting the certificate in the browser (FireFox is usually more informative than Chrome), and look for the error-code.
Reasons can be (some of which you have already verified):
Wrong certificate properties (missing the required values in the "usage" attribute)
Wrong domain name
Expired certificate
Certificate could not be verified on the client-side
See this image as an example of an error code:
https://user-images.githubusercontent.com/165314/71407838-14f55a00-2634-11ea-8a30-c119d2eb1eb1.png
1) http and no-dns (working)
I was using nifi on http, and it was working fine. at that time I was accessing it via ip or server name itself. everything was working fine.
2) https (self signed) and no-dns (working)
i did https setup using toolkit and it worked, although chrome kept showing red color message. which was expected. but atleast things worked.
3) dns (internal) + signed certificate (external authority (Symantec))
dns works fine, as I am able to ping the box using dns. also i added this dns to etc host file.
even though nifi is internal to org, I still went head and bought a certificate. and CNAME i used was the dns name of my server.
certificate i got was a chained certificate
my_dns_>TrustedSecureCertificateAuthority5>USERTrustRSAAddTrustCA>AddTrustExternalCARoot
I create a JKS, and added all of them in it, also added a key_pair to JKS, and I appended all certificated to key_pair too.
Then I changed nifi.properties and used same jks as trust-store and key-store.
now if i use nifi with new dns and https, i am getting "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" (attached image) on Chrome. On IE, i get a TLS error. so I dont think thr is something wrong either with certificate or browser.
if I give url as (see image) https://server_name:9447/nifi, nifi opens up..with but still shows up red color warning, but this time is not for self signed certificate, but for name not matching. which confirms that nifi web server has access to my new jks, and it also reads it...but then why it is not working?
what am i missing here? can nifi run on externally bought certificate? or it always has to work with self-signed certificate?
if you are running nifi with external certified certificate, please share your configuration.
do I still have to use toolkit? or toolkit does same thing, which i did by buying the certificate? if true, what am i missing here?
so here is how i resolved it.
after nothing worked. I went back to https setup of nifi, where nifi generates keystore and truststore jks.
and then i downloaded both, and edited it. I removed all previous certificates (self signed one). and then added my CA certificate chain.
then simply uploaded them back. then just restarted nifi.
nifi is now on https.
I'm trying to get a cert to work with a dev url on my local machine.
I've generated a self signed cert using keytool and have it connected with jboss. In chrome I can click on the lock with the x in it to view the cert details.
I downloaded the cert, added it to System and set the trust level to Always Trust. As per directions in Getting Chrome to accept self-signed localhost certificate . Then I loaded the page (even restarted browser, followed by system reboot to make sure everything was picked up).
I still see the lock with red x in chrome, for my dev url, 127.0.0.1, and localhost. What am I doing wrong to get chrome to trust the site for the local host, which is followed by the real question, which is do I need to anything special to get it to work for my dev url?
My hosts file has the dev url and localhost resolving to 127.0.0.1. When doing real certs I know the domain has to be specified, which is making me wonder if I need to do anything special for the custom dev url.
I finally figured out my issue and am posting the answer for anyone else who runs into the same problem. I also posted the answer in the referenced question.
The question referenced has an answer suggest by bjnord, Google Chrome, Mac OS X and Self-Signed SSL Certificates. This blog did not solve the problem directly, however there was a comment to the blog that was gold:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain site.crt
You pretty much have to follow the directions in the blog to get the cert, then use the command above to install it properly.
I also found that for the java keytool that when you are prompted for your first and last name, this acts like the CN, so you enter your url there instead. After doing this, everything worked fine with the custom dev url.
I've got an intranet site setup which uses an SSL cert with a self-signed CA. On one of my Macs, Safari refuses to connect, with the "Safari can't open the page .. because Safari can't establish a secure connection to the server .." The Mac is running 10.11 (El Capitan) with the latest patch.
Chrome and Firefox are both able to connect to that server.
Safari is willing to connect to it if I use the IP address instead of the
DNS name.
In the logs I see com.apple.WebKit.Networking[3382]:
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
Another Mac on the LAN is happy to connect to the machine by its DNS name
I suspect there's something wrong in the keychain, but I can't find any certs nor revocations for anything related to either the DNS name of the machine, or its CA.
Any suggestions how to debug this are very welcome. The other StackOverflow articles seem unrelated to my issue.
My solution to this issue was to revert my Apache Configuration SSL Cipher Suite back to the default setting in WHM. Hopefully this may be of help.
I recently ran into a similar issue with an iOS device on an intranet. I installed the self-signed root and issuing certificates on the phone, but continued to receive the message. After a lot of trial and error, I found that manually changing the DNS setting (tapping the 'i' icon next to the active wifi connection in the wifi settings) to Google's public DNS ("8.8.8.8") solved the problem.
I have been using a wildcard SSL certificate for several of my company's B2B websites for some time. Recently, we noticed that Google Chrome started displaying a red unlocked lock with HTTPS crossed out for all of these websites. The solution I found was to reissue the certificate from the provider (Network Solutions). So, I did this, and updated the certificate for each of the websites, and the Google Chrome issue went away (HOORAY!). However, when visiting any of these websites in Firefox, it displays a security message stating the website is using an invalid security certificate:
How can I resolve this so that our users are not confused when visiting these websites?
P.S. These websites are running on IIS6.
It looks as if the certificate chain is incomplete and, thus, Firefox (and likely other browsers) cannot verify the site certificate. Normally browsers store intermediate certificates they have seen in the past - that might be a reason why it works in Chrome.
You can test using https://www.ssllabs.com/ssltest/analyze.html.
Depending on the server software (here, for Apache httpd and other servers which read the certificate in PEM/DER format), you can just paste the intermediate certificates together with the certificate in one .pem file (which is used as Certificate file).
The chain (intermediate certificates) is/are normally provided by your CA. In your case you could also use Chrome the review the certificate and then store/extract all intermediate certificates from the certificate view.
You can get this certificate is not trusted error if server doesn't send a required intermediate certificate.
Firefox automatically stores intermediate certificates that servers send in the Certificate Manager for future usage.
If a server doesn't send a full certificate chain then you won't get an untrusted error when Firefox has stored missing intermediate certificates from visiting a server in the past that has send it, but you do get an untrusted error if this intermediate certificate isn't stored yet.
You can inspect the certificate chain via a site like this:
http://www.networking4all.com/en/support/tools/site+check/
I followed the instructions at enter link description here, to import the intermediate certificates.
In IIS, there is an option under Directory Security to "Enable certificate trust list". I enabled it and added the "AddTrust External CA Root" to the CTL certificates list and this appears to have fixed the issue.