connecting Chrome to a local development WebLogic that was using a WebServer certificate that was revoked in the CRL list, I got this message:
Your connection is not private
Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards).
NET::ERR_CERT_REVOKED
Automatically report details of possible security incidents to Google. Privacy policy
ReloadHide advanced
localhost normally uses encryption to protect your information. When Google Chrome tried to connect to localhost this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be localhost, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
You cannot visit localhost right now because this certificate has been revoked. Network errors and attacks are usually temporary, so this page will probably work later.
Once I started Chrome with "chrome.exe --ignore-certificate-errors" the connection is accepted, I just get a warning "you are using an unsupported command-line flag: --ignore-certificate-errors. Stability and security will suffer "
Showing posts with label certificate. Show all posts
Showing posts with label certificate. Show all posts
Saturday, February 18, 2017
Thursday, July 30, 2015
Using Subject Alternative Names in certificates
if your site can be served via more than 1 hostname, you might have to set a "Subject Alternative Name" (SAN) with a comma separated list of all your valid hostnames.
The MAD thing is that is you use a SAN, your MAIN Common Name (certificate SUbject) will be ignored. So in your SAN list you should specify also the hostname that used to go in the Main subject.
Unless you do that, you will get a "Server's certificate does not match URL" in Chrome, or a "Mismatched Address" in IE. IE really stinks because its error message gives absolutely no extra info, while Chrome gives some extra context information. Shame on Microsoft.
Chrome full message says "This server could not prove that it is bla.acme.net; its security certificate is from pippo.acme.net . This may be caused by a misconfiguration or an attacker intercepting your connection"
The RFC which could bring some order in this chaos is here https://tools.ietf.org/html/rfc6125 and search for subjectAlternativeName .
The MAD thing is that is you use a SAN, your MAIN Common Name (certificate SUbject) will be ignored. So in your SAN list you should specify also the hostname that used to go in the Main subject.
Unless you do that, you will get a "Server's certificate does not match URL" in Chrome, or a "Mismatched Address" in IE. IE really stinks because its error message gives absolutely no extra info, while Chrome gives some extra context information. Shame on Microsoft.
Chrome full message says "This server could not prove that it is bla.acme.net; its security certificate is from pippo.acme.net . This may be caused by a misconfiguration or an attacker intercepting your connection"
The RFC which could bring some order in this chaos is here https://tools.ietf.org/html/rfc6125 and search for subjectAlternativeName .
Labels:
certificate
Monday, May 11, 2015
java.security.cert.CertificateException: no trust anchor defined
Or also "Trust anchor for certification path not found "
If you see a "java.security.cert.CertificateException: no trust anchor defined", most likely it means that someone has messed up the Certificate, for instance replacing a trusted CA certificate with a Self-Signed certificate.
you can use "openssl s_client -debug -connect yourhost:yourport" and check for the dreaded "verify error:num=18:self signed certificate"
In case you use an Oracle Wallet to hold certificates, you can do a
orapki wallet display -wallet /path/to/wallet -summary
http://docs.oracle.com/cd/B28359_01/network.111/b28530/asoappf.htm#i636653
Here https://medium.com/@kibotu/handling-custom-ssl-certificates-on-android-and-fixing-sslhandshakeexception-65ffb9dc612e some troubleshooting is suggested
#this to display the server's certificates
openssl s_client -connect myserver.com:443 -showcerts
#to save server cert to pem format
openssl s_client -connect google.com:443 -showcerts < /dev/null 2> /dev/null | openssl x509 -outform PEM > googlecert.pem
The JVM trusted CA certs are in $JAVA_HOME/jre/lib/security/cacerts
To add an entry in cacerts:
keytool -import -trustcacerts -keystore cacerts -storepass changeit -alias googleca -import -file googlecert.pem
To examine the content of cacerts , use https://keystore-explorer.org/
To dump all your trustedCA()
Here https://nakov.com/blog/2009/07/16/disable-certificate-validation-in-java-ssl-connections/ a dirty trick to trust all certificates:
If you see a "java.security.cert.CertificateException: no trust anchor defined", most likely it means that someone has messed up the Certificate, for instance replacing a trusted CA certificate with a Self-Signed certificate.
you can use "openssl s_client -debug -connect yourhost:yourport" and check for the dreaded "verify error:num=18:self signed certificate"
In case you use an Oracle Wallet to hold certificates, you can do a
orapki wallet display -wallet /path/to/wallet -summary
http://docs.oracle.com/cd/B28359_01/network.111/b28530/asoappf.htm#i636653
Here https://medium.com/@kibotu/handling-custom-ssl-certificates-on-android-and-fixing-sslhandshakeexception-65ffb9dc612e some troubleshooting is suggested
#this to display the server's certificates
openssl s_client -connect myserver.com:443 -showcerts
#to save server cert to pem format
openssl s_client -connect google.com:443 -showcerts < /dev/null 2> /dev/null | openssl x509 -outform PEM > googlecert.pem
The JVM trusted CA certs are in $JAVA_HOME/jre/lib/security/cacerts
To add an entry in cacerts:
keytool -import -trustcacerts -keystore cacerts -storepass changeit -alias googleca -import -file googlecert.pem
To examine the content of cacerts , use https://keystore-explorer.org/
To dump all your trustedCA()
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;
import java.security.KeyStore;
import java.security.cert.X509Certificate;
import java.util.Arrays;
public class TM {
public static void main(String[] args) throws Exception {
TrustManagerFactory factory = TrustManagerFactory.getInstance("X509");
factory.init((KeyStore) null);
TrustManager[] tms = factory.getTrustManagers();
X509TrustManager tm = (X509TrustManager) tms[0];
X509Certificate[] ai = tm.getAcceptedIssuers();
Arrays.stream(ai).forEach(item -> System.out.println(item.toString()));
}
}
Here https://nakov.com/blog/2009/07/16/disable-certificate-validation-in-java-ssl-connections/ a dirty trick to trust all certificates:
import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URL;
import java.net.URLConnection;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.security.cert.X509Certificate;
public class Example {
public static void main(String[] args) throws Exception {
// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[] {new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}
};
// Install the all-trusting trust manager
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
// Create all-trusting host name verifier
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
// Install the all-trusting host verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
URL url = new URL("https://www.nakov.com:2083/");
URLConnection con = url.openConnection();
Reader reader = new InputStreamReader(con.getInputStream());
while (true) {
int ch = reader.read();
if (ch==-1) {
break;
}
System.out.print((char)ch);
}
}
}
Labels:
certificate,
security,
ssl,
TrustManager,
X509Certificate,
X509TrustManager
Tuesday, July 22, 2014
Revocation information for the security certificate for this site is not available.
one of our workstations was getting regularly this popup "Revocation information for the security certificate for this site is not available. Do you want to proceed?". It's a Windows 7 machine.
Clicking on "view certificate" it was showing one of our certificates. Opening the certificate we discovered that there is a Certificate Revocation List
They tried "Start, then Control Panel, then Internet Options, then Clear SSSL State", they also checked that the date/time was correct.
This article http://www.brighthub.com/internet/security-privacy/articles/82291.aspx is a sort of universal source of truth for this issue.
Then we discovered simply that the CRL URL was not accessible from that workstation, because the proxy was blocking it. Granting access to that URL solved the issue.
Clicking on "view certificate" it was showing one of our certificates. Opening the certificate we discovered that there is a Certificate Revocation List
They tried "Start, then Control Panel, then Internet Options, then Clear SSSL State", they also checked that the date/time was correct.
This article http://www.brighthub.com/internet/security-privacy/articles/82291.aspx is a sort of universal source of truth for this issue.
Then we discovered simply that the CRL URL was not accessible from that workstation, because the proxy was blocking it. Granting access to that URL solved the issue.
Labels:
certificate,
security,
windows
Subscribe to:
Posts (Atom)