I recently came up to this problem too, this is not documented but it seems that calling method onReceivedSslError on Android 4.4 KitKat depends on the type of SSL error. I checked these two cases:
If the SSL error is due to a self signed server certificate, it does invoke onReceivedSslError method in Android KitKat 4.4, as it did in older versions.
However, if the SSL error cause is a bad certificate chain (LogCat showing the message: "Failed to validate the certificate chain, error: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.", then onReceivedSslError is not called in KitKat, as it was called in older Android versions, and thus the error cannot be ignored or bypassed in 4.4. This was my case, and I do not know whether this is a bug or done on purpose to prevent MITM attacks, but I did not find a programmatic way to work around this.
The underlying problem for me was that the web server did not expose the full certificate chain but only the last certificate, leaving to the device the responsibility to validate the full chain, provided it has all the certificates stored in the device cert store, which was not the case for Android devices.
You could make sure if this was also your problem either by:
a) Checking the certificate chain with an online certificate checker, such as: http://www.digicert.com/help/
b) Using openssl to verify the received certificate chain:
openssl s_client -showcerts -connect :443
You can there see the certificate chain, which should contain two or more certificates, and if the result ends with something like:
Verify return code: 21 (unable to verify the first certificate),
you are likely to have a similar problem as I had.
The solution was to fix the web server configuration so the server exposes the full certificate chain to the hosts.