A better solution that won’t get you man in the middled.
I was dealing with this and quite frankly allowing MITM attacks is a no-no. Here is a cleaner solution that supports pinning. Save the certificate into your raw resource folder.
NOTE: Sadly, SSLError gives us an SslCertificate when you call getCertificate(). SslCertificate is kind of useless. It’s public API doesn’t allow you to verify the public key, only the created on, expired date, issued to, issued by. However, if you open up this class you will see an X509Certificate member variable that is un-exposed. IDK why this design decision was taken. But there is an API for getting the Bundle, and that X509 Certificate member variable gets stored in there. So we access it that way, because the Certificate has a lot more useful methods on it.
@Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
SslCertificate sslCertificateServer = error.getCertificate();
Certificate pinnedCert = getCertificateForRawResource(R.raw.your_cert, mContext);
Certificate serverCert = convertSSLCertificateToCertificate(sslCertificateServer);
if(pinnedCert.equals(serverCert)) {
handler.proceed();
} else {
super.onReceivedSslError(view, handler, error);
}
}
public static Certificate getCertificateForRawResource(int resourceId, Context context) {
CertificateFactory cf = null;
Certificate ca = null;
Resources resources = context.getResources();
InputStream caInput = resources.openRawResource(resourceId);
try {
cf = CertificateFactory.getInstance("X.509");
ca = cf.generateCertificate(caInput);
} catch (CertificateException e) {
Log.e(TAG, "exception", e);
} finally {
try {
caInput.close();
} catch (IOException e) {
Log.e(TAG, "exception", e);
}
}
return ca;
}
public static Certificate convertSSLCertificateToCertificate(SslCertificate sslCertificate) {
CertificateFactory cf = null;
Certificate certificate = null;
Bundle bundle = sslCertificate.saveState(sslCertificate);
byte[] bytes = bundle.getByteArray("x509-certificate");
if (bytes != null) {
try {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
Certificate cert = certFactory.generateCertificate(new ByteArrayInputStream(bytes));
certificate = cert;
} catch (CertificateException e) {
Log.e(TAG, "exception", e);
}
}
return certificate;
}
SSL certificate_verify_failed errors typically occur as a result of outdated Python default certificates or invalid root certificates. We will cover how to fix this issue in 4 ways in this article.
Why certificate_verify_failed happen?
The SSL connection will be established based on the following process. We will get errors if any of these steps does not go well.
For this error certificate_verify_failed, it usually happens during step 2 and step 3.
- The client sends a request to the server for a secure session. The server responds by sending its X.509 digital certificate to the client.
- The client receives the server’s X.509 digital certificate.
- The client authenticates the server, using a list of known certificate authorities.
- The client generates a random symmetric key and encrypts it using server’s public key.
- The client and server now both know the symmetric key and can use the SSL encryption process to encrypt and decrypt the information contained in the client request and the server response.
When the client receives the server’s certificate, it begins chaining that certificate back to its root. It will begin by following the chain to the intermediate that has been installed, from there it continues tracing backwards until it arrives at a trusted root certificate.
If the certificate is valid and can be chained back to a trusted root, it will be trusted. If it can’t be chained back to a trusted root, the browser will issue a warning about the certificate.
Related: Check SSL Certificate Chain with OpenSSL Examples
Error info about certificate_verify_failed
We will see the following error.
<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:777)>
What is SSL certificate
Server certificates are the most popular type of X.509 certificate. SSL/TLS certificates are issued to hostnames (machine names like ‘ABC-SERVER-02’ or domain names like google.com).
A server certificate is a file installed on a website’s origin server. It’s simply a data file containing the public key and the identity of the website owner, along with other information. Without a server certificate, a website’s traffic can’t be encrypted with TLS.
Technically, any website owner can create their own server certificate, and such certificates are called self-signed certificates. However, browsers do not consider self-signed certificates to be as trustworthy as SSL certificates issued by a certificate authority.
Related: 2 Ways to Create self signed certificate with Openssl Command
How to fix certificate_verify_failed?
If you receive the “certificate_verify_failed” error when trying to connect to a website, it means that the certificate on the website is not trusted. There are a few different ways to fix this error.
We will skip the SSL certificate check in the first three solutions. For the fourth solution, we are going to install the latest CA certificate from certifi.
Create unverified context in SSL
import ssl
context = ssl._create_unverified_context()
urllib.request.urlopen(req,context=context)
Create unverified https context in SSL
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
urllib2.urlopen(“https://google.com”).read()
Use requests module and set ssl verify to false
requests.get(url, headers=Hostreferer,verify=False)
Update SSL certificate with PIP
we can also update our SSL certificate With PIP. All we would have to do is to update our SSL certificate directory with the following piece of code: pip install –upgrade certifi
What this command does is update our system’s SSL certificate directory.
Reference:
Understanding SSL certificates
Check SSL Certificate Chain with OpenSSL Examples
5 ways to check SSL Certificate
The reason why the webview fail to load the url is the SSL certificate.
when the webview fail to validate an ssl ceriticate it throws an exception
(error: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.)
then the method
onReceivedSslError(WebView view, SslErrorHandler handler, SslError error)
is called if not @overrided by default the processing of the url is canceled otherwise if implemented we have different types of ssl errors that comes in SsError object we should force the processing of the url by calling handler.process
see bellow the implementation and the cases that u should handle also u can debug and understand what the real matter with ur URL ssl certificate:
@Override
public void onReceivedSslError(WebView view, SslErrorHandler handler,
SslError error) {
switch (error.getPrimaryError()) {
case SslError.SSL_UNTRUSTED:
LogUtility.debug("SslError : The certificate authority is not trusted.");
break;
case SslError.SSL_EXPIRED:
LogUtility.debug("SslError : The certificate has expired.");
break;
case SslError.SSL_IDMISMATCH:
LogUtility.debug("The certificate Hostname mismatch.");
break;
case SslError.SSL_NOTYETVALID:
LogUtility.debug("The certificate is not yet valid.");
break;
}
handler.proceed();
}
Please note also that, sometimes an app is not published to the PlayStore because of this, cause we should provide a popup message with a yes or no to let the user decide if he agree to open the url even if there’s an ssl certificate issue or no.
I don’t know but there should be a way to force the process of validation of the ssh certificate from the web
I have encountered a problem that is similar to yours, with the Ubuntu Server installed in a VM, but the underlying cause should be different. I put out the problem description and the solution in case that someone who encountered the same problem reaches here.
Brief Summary:
The similar problem is caused by the network condition of our office. When the problem occurs, I used a bridged network for Internet access. After changing the VM network setting to the normal NAT, the problem is mitigated.
Background:
I have installed Ubuntu Server LTS 18.04.3 with VMWare Player. After the installation is completed, I have used the VM for several days, including upgrading the system with sudo apt update|upgrade and install new applications with sudo apt install <appname>.
Problem:
After a weekend, I reopen the VM and want to install some new software. So I first try to update the repository information with sudo apt update to see if there are something that is upgradable. However, after executing this command, I get the following results:
gary@ubuntu-vm:~$ sudo apt update
Ign:1 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic InRelease
Ign:2 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates InRelease
Ign:3 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports InRelease
Ign:4 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security InRelease
Err:5 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic Release
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:6 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates Release
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:7 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports Release
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Err:8 https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security Release
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 101.6.8.193 443]
Reading package lists... Done
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-updates Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-backports Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: The repository 'https://mirrors.tuna.tsinghua.edu.cn/ubuntu bionic-security Release' no longer has a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
which is similar to the aseked problem(e.g., Ign:3 and Err:5), but not the same.
Solution:
I have searched the related topics on Google, and many said that the problem is caused by incorrect configuration of certificates. However, I should never change any certificate configuration after installation of the system. Besides, avoiding certificates authentication should not be a regular routine.
To make sure that I did not change related configurations, I reinstall the system. I found that the installation cannot be completed, with the error log similar to the above one. After finding this, I guess that this problem should be caused by the network connection problem, as in this point there is no configuration made to the system.
Therefore, I checked the configuration of the VM instance, and found that this VM uses a bridged network rather than NAT. So I changed the network setting to NAT, which is usually the default network setting, then everything returns to normal!
After that, I recalled that when I first install the VM, I connect my computer to another computer to share the network (using NAT at the second computer). Later, I have my own network connection and I want the VM direct access to the physical network, so I changed the VM network setting to a bridged network, which then caused the problem (It’s simply a network connection problem, because the physical network require authentication for network connection, while the VM does not have the credentials).