Der Pfad kleidet sich mit keinem der Vertrauensanker ⇐ Java

[Anonymous]

Ich versuche, eigenständige Wiremock einzurichten, um das Client -Zertifikat zu überprüfen.java -Djavax.net.debug=all -Djava.security.debug=certpath -jar wiremock3.jar --port 9080 --https-port 9443 --https-keystore ./certificates/server/server_cert.jks --keystore-password qwerty --key-manager-password qwerty --https-require-client-cert --https-truststore ./certificates/client/truststore.jks --truststore-password qwerty --verbose
< /code>
Aber wenn ich versuche, mich von meinem Client zu verbinden, habe ich einen Fehler: < /p>
javax.net.ssl|ERROR|E2|qtp1927963027-46|2025-06-19 19:31:52.728 MSK|TransportContext.java:370|Fatal (CERTIFICATE_UNKNOWN): PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors (
"throwable" : {
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:318)
at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:256)
at java.base/sun.security.validator.Validator.validate(Validator.java:256)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:284)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:138)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkClientCerts(CertificateMessage.java:674)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:405)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:393)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:476)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1273)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1260)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:714)
at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1205)
at wiremock.org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.fill(SslConnection.java:674)
at wiremock.org.eclipse.jetty.http2.HTTP2Connection.fill(HTTP2Connection.java:165)
at wiremock.org.eclipse.jetty.http2.HTTP2Connection$HTTP2Producer.produce(HTTP2Connection.java:359)
at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produceTask(AdaptiveExecutionStrategy.java:514) at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:258) 19:36 at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.produce(AdaptiveExecutionStrategy.java:195) at wiremock.org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:209) at wiremock.org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:156) at wiremock.org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:442) at wiremock.org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) at wiremock.org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:575) at wiremock.org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:390) at wiremock.org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150) at wiremock.org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) at wiremock.org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:480) at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:443) at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) at wiremock.org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) at wiremock.org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311) at wiremock.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981) at wiremock.org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211) at wiremock.org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:157) at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:83) at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309) at java.base/sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:313) ... 37 more}
< /code>
In Protokollen sehe ich, dass die Zertifikate gut sind: < /p>
"CertificateRequest": {
"certificate types": [ecdsa_sign, rsa_sign, dss_sign]
"supported signature algorithms": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, ed448, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
"certificate authorities": [CN=Root CA, O=TLS Experts, L=Oslo, ST=Oslo, C=NO, CN=Intermediate CA, O=TLS Experts, L=Oslo, ST=Oslo, C=NO]
}
< /code>
und Client senden die erforderliche Zertifikatskette (wie Sie sehen können, wird von einem Intermediate -Cert in der Liste der Zertifikatbehörden ausgestellt) < /p>
javax.net.ssl|DEBUG|F2|qtp1540894701-47|2025-06-19 19:37:45.740 MSK|CertificateMessage.java:366|Consuming client Certificate handshake message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "327A90FA4BBCF1859AD5DFE2ECF9267FBA35AFEC",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=Intermediate CA, O=TLS Experts, L=Oslo, ST=Oslo, C=NO",
"not before" : "2025-06-06 08:42:41.000 MSK",
"not after" : "2026-06-06 08:42:41.000 MSK",
"subject" : "EMAILADDRESS=thor@tls-experts.no, CN=Thor Odinson, O=TLS Experts, L=Oslo, ST=Oslo, C=NO",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[
accessMethod: ocsp
accessLocation: URIName: http://srv8-beattownma:9999/
]
]
},
{
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 26 1F 3B 38 59 AB F2 6C 9B 7E C0 82 FA CA EF 1A &.;8Y..l........
0010: 88 AE 0F A0 ....
]
]
},
{
ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
},
{
ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http://crl.tls-experts.no/intermediate_crl.der]
]]
},
{
ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
clientAuth
emailProtection
]
},
{
ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
]
},
{
ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
SSL client
S/MIME
]
},
{
ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
RFC822Name: postmaster@tls-experts.no
RFC822Name: hostmaster@tls-experts.no
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 73 88 04 13 F6 AC 40 D7 AF D6 B3 B1 81 DF 71 99 s.....@.......q.
0010: 4A 55 6D 99 JUm.
]
]
}
]},
"certificate" : {
"version" : "v3",
"serial number" : "5E9375F2B7DC3D06E632BCF5C948D8DDD06021DB",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=Root CA, O=TLS Experts, L=Oslo, ST=Oslo, C=NO",
"not before" : "2025-02-26 07:40:29.000 MSK",
"not after" : "2035-02-24 07:40:29.000 MSK",
"subject" : "CN=Intermediate CA, O=TLS Experts, L=Oslo, ST=Oslo, C=NO",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 3C CC BF EA EB 0D 27 D1 F0 9B A2 F2 64 DD DD 2B
Also versucht Validator, die wichtigsten Key -IDs zu entsprechen, und sie sind unterschiedlich ...
Ich habe meine Zertifikate und Betreff -Key -IDs wirklich unterschiedlich überprüft. Aber warum vergleicht Java Betreffschlüssel?