Discovery reports Certificate for <domain> doesn't match any of the subject alternative names
#1805
Comments
jackjia-ibm
added
bug
|
This is the keystore/truststore I used for above test: test-keystore.zip And with this keystore/truststore pair, all APIML services can be started and Discovery can see all services registered correctly. |
achmelo
added
clarification
|
@jackjia-ibm Makes me think that the exception is thrown for a valid reason the discovery-0.discovery-service.zowe.svc.cluster.local consists of 6 fragments, but the certificate SAN has 5 fragments and wilcard on the first position, so I would not anticipate it to match the provided hostname |
|
This is the Tomcat code that does the wildcard verification fyi: // RFC 2818, 3.1. Server Identity
// "...Names may contain the wildcard
// character * which is considered to match any single domain name
// component or component fragment..."
// Based on this statement presuming only singular wildcard is legal
final int asteriskIdx = identity.indexOf('*');
if (asteriskIdx != -1) {
final String prefix = identity.substring(0, asteriskIdx);
final String suffix = identity.substring(asteriskIdx + 1);
if (!prefix.isEmpty() && !host.startsWith(prefix)) {
return false;
}
if (!suffix.isEmpty() && !host.endsWith(suffix)) {
return false;
}
// Additional sanity checks on content selected by wildcard can be done here
if (strict) {
final String remainder = host.substring(
prefix.length(), host.length() - suffix.length());
if (remainder.contains(".")) {
return false;
}
}
return true; |
|
Regarding why this shows in Discovery service even with http hostname verification disabled I'm checking that
Are you sure these keys are correct? |
|
Thanks David, you are right, after I put For your question, yes |
|
Regarding the log, the debug logging is appropriate for such messages and I don't think it's a problem. |
Describe the bug
After Discovery is started in Kubernetes, a lot of errors repeated showing in pod log:
This error message is always showing even
APIML_DEBUG_MODE_ENABLED,ZOWE_APIM_VERIFY_CERTIFICATES, andZOWE_APIM_NONSTRICT_VERIFY_CERTIFICATESare allfalse.While using same keystore/truststore and validate against certificate-analyser.jar,
https://localhost:7553/eureka/apps, the handshake will be successful.https://discovery-0.discovery-service.zowe.svc.cluster.local:7553/eureka/apps, the handshake will fail.In
/etc/hosts, we pointdiscovery-0.discovery-service.zowe.svc.cluster.localto127.0.0.1, so it's same aslocalhost.Steps to Reproduce
16c9219e768436c70f5e14c09decff5522190da3.127.0.0.1 discovery-0.discovery-service.zowe.svc.cluster.localto/etc/hostsExpected behavior
Certificate should be accepted.
Logs
Please confirm if you can reproduce the error. Thanks.
The text was updated successfully, but these errors were encountered: