Sorry for opening another question with the same topic, but i think this sub-question would bloat the other one into oblivion.
I run into the mentioned error message, which is quite unspecific (at least for me). The debug output shows the certificates are loaded and then only the mentioned error. I generated the test certificate with its own CA chain:
CA -> SubCA -> ClientCert
I try to connect a client and a server on the same machine (to test a two way protocol) with SSL.
I generate my ca certificates using these commands:
openssl req -batch -x509 -config ${ROOTCA_CONFIG} -newkey rsa:2048 -sha1 -nodes -out ${ROOTCA_CERT} -outform PEM -days 7300
openssl req -batch -config ${SUBCA_CONFIG} -newkey rsa:2048 -sha1 -nodes -out ${SUBCA_CSR} -outform PEM
openssl ca -batch -config ${ROOTCA_CONFIG} -policy signing_policy -extensions signing_req_CA -out ${SUBCA_CERT} -infiles ${SUBCA_CSR}
They seem to be fine. The only thing that puzzles me is: If concatenate both certificates into a single file and verify them with that chain, it is fine. If it try to verify with subCA or the root CA only, verification fails.
Then i create my client/server cert:
openssl req -batch -config ${CLIENT_CONFIG} -newkey rsa:2048 -sha256 -nodes -out ${CLIENT_CSR} -outform PEM -keyout $1.key
openssl ca -batch -config ${SUBCA_CONFIG} -policy signing_policy -extensions signing_req -out ${CLIENT_CERT} -infiles ${CLIENT_CSR}
With this i create a PKCS12 file to use in my keystore:
openssl pkcs12 -export -inkey ${CONNECTOR_KEY} -in ${CONNECTOR_CERT} -out ${CONNECTOR_P12}
I do this by calling my script twice, once for the server and once for the client. Let's call them client.cert and server.cert, even if client/server is confusing since they both are local protocol endpoints.
I then use these commands to generate the truststore and keystore for client and server:
keytool -keystore $2-truststore.jks -importcert -alias ca -file test_ca_certs/rootca.cert
keytool -keystore $2-truststore.jks -importcert -alias subca -file test_ca_certs/subca.cert
keytool -v -importkeystore -srckeystore $1 -srcstoretype PKCS12 -destkeystore $2-keystore.jks -deststoretype JKS
Let $2 be client and server each (server-truststore etc.) and $1 be the same as ${CONNECTOR_P12} before (somefile.p12)
So now i have a truststore with CA and SubCA and a keystore with the PKCS12 Token. Truststore is the same on client and server side, Token is pretty much the same, but has different keypairs, since they are generated each time.
The ssl debug output indicates the certs are loaded:
keystore (...) has type [jks], and contains aliases [1].
***
found key for : 1
chain [0] = [
[
Version: V3
Subject: CN=cnname, OU=ouname, O=oname, L=location, ST=bavaria, C=DE
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 2999...
public exponent: 65537
...
...
keystore has type [jks], and contains aliases [ca, subca].
adding as trusted cert:
Subject: CN=my Root CA 2016, O=organization, C=DE
Issuer: CN=my Root CA 2016, O=organization, C=DE
Algorithm: RSA; Serial number: 0xfc8239c0355555c1
Valid from Wed Oct 19 10:14:36 CEST 2016 until Tue Oct 14 10:14:36 CEST 2036
adding as trusted cert:
Subject: CN=my SubCA 2016, O=Fraunhofer, C=DE
Issuer: CN=my Root CA 2016, O=Fraunhofer, C=DE
Algorithm: RSA; Serial number: 0x1
Valid from Wed Oct 19 10:14:38 CEST 2016 until Thu Oct 17 10:14:38 CEST 2024
Is there some general flaw in my understanding? Again, sorry for posting two questions but i start to believe i do something wrong in a more fundamental fashion. Thanks!
I finally found the solution. I only set debugging to SSL. This was my mistake. I would have needed to set the debug output to "all". Then i can see this error message:
Caused by: sun.security.validator.ValidatorException: Extended key
usage does not permit use for TLS server authentication
This is much more specific. To fix that, indeed i needed to change my extended key usage to this:
keyUsage = digitalSignature, keyEncipherment, nonRepudiation
extendedKeyUsage = clientAuth, serverAuth
Thank you very much!
Related
I have an Apache CXF client that is connecting a SOAP service, and authenticating with mutual TLS. The client fails during the TLS Handshake because the service sends an empty list of client certificates to the server. I am testing this with self-signed certs, and I can prove that my server works with a curl request and with postman. I am pretty sure that the certificates are setup correctly, and I am sure that I am missing a config step in the CXF client.
Here is how I have my client setup
// setting up certs & keystores
String keystore = "client-keystore.jks";
String keystorePassword = "changeit"; // local self-signed certs
String trustStore = "truststore.jks";
String trustStorePassword = "changeit"; // local self-signed certs
// client keystore
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), keystorePassword.toCharArray());
// ca truststore
KeyStore ts = KeyStore.getInstance("JKS");
ts.load(new FileInputStream(trustStore), trustStorePassword.toCharArray());
// key managers
var kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, keystorePassword.toCharArray());
KeyManager[] kms = kmf.getKeyManagers();
// trust managers
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ts);
TrustManager[] tms = tmf.getTrustManagers();
TLSClientParameters param = new TLSClientParameters();
param.setSecureSocketProtocol("TLSv1.2");
param.setDisableCNCheck(false);
param.setTrustManagers(tms);
param.setKeyManagers(kms);
// Get the client & setup the tls parameters
BindingProvider bp = (BindingProvider) port;
var client = ClientProxy.getClient(bp);
HTTPConduit https = (HTTPConduit)client.getConduit();
https.setTlsClientParameters(param);
Here is how I created the certificates. My java version is azul zulu openjdk 11.
# Create the CA Authority that both the client and server can trust
openssl req -new -x509 -nodes -days 365 -subj '/CN=my-ca' -keyout ca.key -out ca.crt
# Create the server's key, certificate signing request, and certificate
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj '/CN=localhost' -out server.csr
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 365 -out server.crt
# Create the client's key, certificate signing request, and certificate
openssl genrsa -out client.key 2048
openssl req -new -key client.key -subj '/CN=my-client' -out client.csr
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 365 -out client.crt
openssl x509 --in client.crt -text --noout
# Create the root truststore
keytool -import -alias my-ca -file ca.crt -keystore truststore.jks
# Create pkcs12 file for key and cert chain
openssl pkcs12 -export -name server-tls -in server.crt -inkey server.key -out server.p12
# Create JKS for server
keytool -importkeystore -destkeystore server-keystore.jks -srckeystore server.p12 -srcstoretype pkcs12 -alias server-tls
# Create pkcs12 file for key and cert chain
openssl pkcs12 -export -name client-tls -in client.crt -inkey client.key -out client.p12
# Create JKS for client
keytool -importkeystore -destkeystore client-keystore.jks -srckeystore client.p12 -srcstoretype pkcs12 -alias client-tls
I set debugging on with -Djavax.net.debug=ssl,handshake,data for both the server & the client.
When I use the CXF client to issue a request to the server, it initiates the mutual tls handshake, but the server fails with Fatal (BAD_CERTIFICATE): Empty server certificate chain, and the client fails with Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking...readHandshakeRecord, because it does indeed send an empty certificate list right before hand.
Produced client Certificate handshake message (
"Certificates": <empty list>
)
I have tried a number of different things, but I cannot seem to get the client to work.
Update
Out of curiosity, I ran the ws-security sample from the CXF repo, and used my ca certificate, client, and server certificates in the sample. That worked, and it is configured through an xml bean. I tried the same thing with my local, and it still fails.
The difference between the demo and my client is that when it looks for a x.509 RSA certificate, it fails for my client, but succeeds in the demo app. I have it configured mostly the same.
javax.net.ssl|ALL|01|main|2021-07-02 14:17:32.039 EDT|X509Authentication.java:213|No X.509 cert selected for EC
javax.net.ssl|WARNING|01|main|2021-07-02 14:17:32.040 EDT|CertificateMessage.java:1066|Unavailable authentication scheme: ecdsa_secp256r1_sha256
javax.net.ssl|ALL|01|main|2021-07-02 14:17:32.040 EDT|X509Authentication.java:213|No X.509 cert selected for EC
javax.net.ssl|WARNING|01|main|2021-07-02 14:17:32.040 EDT|CertificateMessage.java:1066|Unavailable authentication scheme: ecdsa_secp384r1_sha384
javax.net.ssl|ALL|01|main|2021-07-02 14:17:32.040 EDT|X509Authentication.java:213|No X.509 cert selected for EC
javax.net.ssl|WARNING|01|main|2021-07-02 14:17:32.040 EDT|CertificateMessage.java:1066|Unavailable authentication scheme: ecdsa_secp521r1_sha512
javax.net.ssl|ALL|01|main|2021-07-02 14:17:32.040 EDT|X509Authentication.java:213|No X.509 cert selected for RSA
javax.net.ssl|WARNING|01|main|2021-07-02 14:17:32.040 EDT|CertificateMessage.java:1066|Unavailable authentication scheme: rsa_pss_rsae_sha256
That last error is not present when using the demo app and instead, it returns back the certificate.
For anyone who stumbles upon this question, here's how I resolved it.
Once I started playing with the CXF demo code, I was able to simplify it to just its bare minimum set of dependencies and configurations. From there I was able to sort out that it was a matter of a missing dependency in my project.
For starters, we use dropwizard for the server, and we have a dependency on dropwizard-jaxws which brings in the cxf dependencies. I found by whittling away all of the layers, that the demo app only works if cxf-rt-transports-http-jetty is in the list of dependencies.
The transitive dependencies that dropwizard-jaxws include are:
cxf-rt-frontend-jaxws
cxf-rt-transports-http
I also had a dependency on all of dropwizard-core in my client which may have implemented some SPI interface that cxf-rt-transports-http-jetty implements (conjecture). Once I simplified the dependencies and included the one missing dependency, I have a repeatable, working solution.
I have a certificate with a generated a CSR within go daddy.
I tried generating my own CSR to get a certificate for my domain.
I have followed their tutorial to generate a store with the CSR:
keytool -genkey -alias codesigncert -keypass -keyalg RSA -keysize 2048 -dname "CN=displayname,O=companyname,C=US,ST=state,L=city" -keystore codesignstore -storepass
But the godaddy rejected the generated CSR, so I used the one they generate.
After that I used this command from a tutorial at thomasvitale.com.:
keytool -import -alias <my alias> -file <downloadedcertificate file>.crt -keystore keystore.p12 -storepass password
The generated .p12 keystore wouldn't boot because spring said:
DerInputStream.getLength(): lengthTag=109, too big.
Reading a LOT on that I have found out it was the way the keystore was generated and the version of something. Because of that I had to generate another keystore.
To generate the current problematic keystore I tried following medium.com instructions:
Used this to generate the keystore:
keytool -genkey -alias <alias> -keyalg RSA -keystore <keystore.jks> -keysize 2048
Used this to generate a CSR:
keytool -certreq -alias <alias> -keystore <keystore.jks> -file <domain>.csr
Sent the CSR to generate the ssl certificates, downloading them using the tomcat option. Then imported the certificates:
intermediate certificate: keytool -import -trustcacerts -alias <alias> -file gd_bundle-g2-g1.crt -keystore <keystore.jks>
root certificate: keytool -import -trustcacerts -alias <alias> -file e2e56xxxxf40c7.crt -keystore <keystore.jks>
Then I created the pcks keystore this way:
keytool -importkeystore -srckeystore <keystore.jks> -destkeystore <keystore.p12> -srcstoretype JKS -deststoretype PKCS12 -deststorepass <password> -srcalias <src alias> -destalias <dest alias>
After that, my spring boot config to install the certificate is:
After comments on this question I changed to use the JKS and removed ciphers.
server:
port: 8443
ssl:
enabled: true
key-store-type: JKS
key-store: classpath:asgard_keystore.jks
key-store-password: generated
key-alias: asgard
After installing all those to the p12, the server started okay, but any requests to the server would yield: err_ssl_version_or_cipher_mismatch or SSL_ERROR_NO_CYPHER_OVERLAP
Capturing that in wireshark just said Alert 21 using TLS 1.2 Handshake Failure (40).
I'm using undertow as a server. I don't remember if I used the domain in the name and last name field of the CSR.
Decoding my CSR using digicert tool I got:
Common name
<my domain>
Organization
<my org>
Organizational unit
<my city>
City/locality
<my city>
State/province
<my estate>
Country
<my country>
Signature algorithm
SHA256
Key algorithm
RSA
Key size
2048
Seems I'm doing everything exactly like every single tutorial, and every time something fails :(
As per the comment on the question, the keytool -list calls:
keytool -list for the .jks:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
Alias name: asgard
Creation date: Dec 7, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 7
Valid from: Tue May 03 07:00:00 UTC 2011 until: Sat May 03 07:00:00 UTC 2031
Certificate fingerprints:
MD5: 96<removed>:40
SHA1: 2<removed>B8
SHA256: 97:3A<removed>E9:76:FF:6A:62:0B:67:12:E3:38:32:04:1A:A6
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: intermediate
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=<removed>, OU=Domain Control Validated
Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Serial number: 5c<removed>
Valid from: Fri Dec 07 20:25:19 UTC 2018 until: Mon Dec 07 18:10:35 UTC 2020
Certificate fingerprints:
MD5: 31<removed>74:77
SHA1: 8D:<removed>:C0:F5:AE:0B
SHA256: 77:14:9<removed>8B:1D:67:46:1A:67:A2:72:2F:2F:9E:F2:16
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
< not relevant >
]
*******************************************
*******************************************
Alias name: server
Creation date: Dec 7, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
Issuer: CN=a<removed>, OU=São Paulo, O=Ideas Farm, L=São Paulo, ST=SP, C=BR
< not relevant >
]
]
*******************************************
*******************************************
full report: pastebin report
I have removed parts of the response that I find not relevant. I found it weird that the pkcs (.p12) file reported as being a jks type.
Also, the files that I received form the certificate authority are:
5<removedhex>6b1b.crt
gd_bundle-g2-g1.crt
gdig2.crt.pem
The gd_bundle contains 3 certificates -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- three times. The other two are just one.
You have told java to use the certificate with an alias of asgard. I can see in your .p12 dump that "asgard" is actually a CA. Look at the owner:
Alias name: asgard
Creation date: Dec 14, 2018
Entry type: trustedCertEntry
Owner: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
I'm guessing that you actually want to tell spring to load your .jks file and specify an alias of codesigncert.
Also, delete your ciphers and enabled-protocols properties unless you have a good reason to override what spring sets up as defaults. Spring keep their defaults up to date with the latest security bulletins.
Finally, change your keystore password because the whole internet now knows what it is :)
I have solved the problem.
After fiddling A LOT with each certificate, I have found out that GoDaddy issues the certificate response and 2 equal intermediate certificates. Both come in the download package and there is no root certificate in there.
What happened is that I had a self signed dummy key, as stated in the comments and I didn't knew that I had to import the server certificate (the certificate response) with the same alias as my private key. I was importing with another alias thinking it was something else. My private key would remain self signed and not validated.
The errors I was getting about ciphers were because I was telling spring to use a certificate that was not a private key. Those don't support decoding the handshake.
Another problem that I faced is that godaddy doesn't provide the root certificate in the bundle you download. I was trying to add two intermediates, while the root was avaliable at a repository they had. After downloading and importing the correct root certificate, then I was able to import the private key validation certificate to the same alias as my dummy key.
So the solutin was simply to start with the JKS keystore used to create the CSR (one that contains only the private key I generated). Then add to it the root and intermediate certificates, and finally add the server cert (the one with the hex name), with the same alias as the private key.
Lets say I have a JAVA client app and it tries to connect to a server (example.com) over https. Client app has a trust store JKS , which has the server's certificate and some other certificates as well. In the hand shake process when server sends it certificate to this client app, how correct certificate will be picked up from the trust store jks. i.e based on what parameters java matches the certificate sent by the server with the certificates stored in JKS.
Matching is done by the certificate's Subject.
E.g. if you browse https://www.google.com/ and look at their certificate, it shows a certificate chain with:
Subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
Issued by: /C=US/O=Google Inc/CN=Google Internet Authority G2
Issued by: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Issues by: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
* Actually obtained using openssl s_client -connect www.google.com:443 -showcerts
The certificate will be trusted if any of these are in your truststore.
You can scan the truststore like this (assuming you have grep):
keytool -list -keystore /path/to/cacerts -storepass changeit -v | grep "CN=GeoTrust Global CA" -B 4 -A 8
To get this kind of output:
Alias name: geotrustglobalca
Creation date: Jul 18, 2003
Entry type: trustedCertEntry
Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Issuer: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
Serial number: 23456
Valid from: Tue May 21 00:00:00 EDT 2002 until: Sat May 21 00:00:00 EDT 2022
Certificate fingerprints:
MD5: F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
SHA1: DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12
SHA256: FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A
Signature algorithm name: SHA1withRSA
Version: 3
My Java client needs to access a resource that is served via a TLS connection. The resource provider uses a self-signed key, namely MM_Base64.cer. I imported their key into a Java keystore and a Java truststore.
For keystore, I issued
keytool -import -keystore D:\mptkeystore.jks -file D:\MM_Base64.cer -alias mpt
and the result is
Enter keystore password:
Re-enter new password:
Owner: CN=client, OU=huawei, O=huawei, L=shenzhen, C=CN
Issuer: CN=client, OU=huawei, O=huawei, L=shenzhen, C=CN
Serial number: 55702f20
Valid from: Thu Jun 04 17:27:36 MMT 2015 until: Sat May 11 17:27:36 MMT 2115
Certificate fingerprints:
MD5: F5:8E:12:58:AC:97:53:CB:8B:B6:E2:DB:C3:F2:48:3D
SHA1: F2:09:23:4C:9A:30:A6:4C:2D:F8:B0:F4:1D:06:41:5C:3A:3E:16:5A
SHA256: 2B:51:BA:48:52:59:82:22:3C:E3:79:93:9E:C5:57:24:A5:9A:6E:08:A2:
7A:C6:FD:02:60:EB:3C:F2:14:53:AB
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore
For trusrstore,
keytool -import -file D:\MM_Base64.cer -alias mit -keystore D:\truststore.jks
Result:
Enter keystore password:
Re-enter new password:
Owner: CN=client, OU=huawei, O=huawei, L=shenzhen, C=CN
Issuer: CN=client, OU=huawei, O=huawei, L=shenzhen, C=CN
Serial number: 55702f20
Valid from: Thu Jun 04 17:27:36 MMT 2015 until: Sat May 11 17:27:36 MMT 2115
Certificate fingerprints:
MD5: F5:8E:12:58:AC:97:53:CB:8B:B6:E2:DB:C3:F2:48:3D
SHA1: F2:09:23:4C:9A:30:A6:4C:2D:F8:B0:F4:1D:06:41:5C:3A:3E:16:5A
SHA256: 2B:51:BA:48:52:59:82:22:3C:E3:79:93:9E:C5:57:24:A5:9A:6E:08:A2:
7A:C6:FD:02:60:EB:3C:F2:14:53:AB
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore
Looks redundant but just in case, being redundant is necessary.
This is how the program gets executed:
java -jar CPS.jar -Djavax.net.ssl.trustStore=D:\truststore.jks -Djavax.net.ssl.trustStorePassword=password -Djavax.net.ssl.keyStore=D:\mptkeystore.jks -Djavax.net.ssl.keyStorePassword=password -Ddeployment.security.SSLv2Hello=false -Ddeployment.security.SSLv3=false -Ddeployment.security.TLSv1=false -Ddeployment.security.TLSv1.1=true -Ddeployment.security.TLSv1.2=true
TLS v1 cannot be used with the service so I disabled it.
It looks as if the handshaking error still occurs. Does anyone see a problem with the way I am doing things?
For adding to truststore i think you would need to add
-trustcacerts
https://docs.oracle.com/cd/E19830-01/819-4712/ablqw/index.html has examples -
keytool -import -v -trustcacerts
-alias keyAlias
-file server.cer
-keystore cacerts.jks
-keypass changeit
-storepass changeit
i have a working soap connection but my certificate is ending. so i only want to change the certificate.
for my soap connection i use a keystore which i generate using openssl.
with my old keystore it works fine. but with my new one i get this stacktrace:
Caused by: org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized
at org.apache.ws.security.validate.SignatureTrustValidator.validate(SignatureTrustValidator.java:86)
at org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:187)
at org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:270)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:120)
at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JInInterceptor.handleMessage(PolicyBasedWSS4JInInterceptor.java:105)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:835)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1612)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1503)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1310)
at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:50)
at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:223)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:628)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
so i guess there is something wrong with my keystore generation.
although i can send the message and it goes wrong with recieving.
this is the code and on the last line i get the above exeption.
AanleverServiceV12_Service service = new AanleverServiceV12_Service();
log.trace("aanleverService created");
AanleverServiceV12 aanleverServicePort = service.getAanleverServicePortV12();
log.trace("aanleverServicePort created");
AanleverRequest aanleverRequest = createAanleverRequest(belastingFormulier);
log.trace("AanleverRequest: {}", aanleverRequest);
AanleverResponse response = aanleverServicePort.aanleveren(aanleverRequest);
this is my config file:
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=pkcs12
org.apache.ws.security.crypto.merlin.keystore.password=****
org.apache.ws.security.crypto.merlin.keystore.file=keystore.p12
org.apache.ws.security.crypto.merlin.keystore.alias={csr_request_finished}
any help would be welcome!
i tried to recreate the keystore which works but i get the same error. so i guess the error is in making the keystore.
i do this:
openssl pkcs12 -export -out keystore.p12 -inkey server.key -in cert.pem -name "{csr_request_finished}"
i updated my generation to this but with the same error (i split the certificate in my own and the supporting certificates:
openssl pkcs12 -export -out kdeb5.p12 -inkey key.pem -in cert.pem -name "{csr_request_finished}" -certfile certRest.pem
ok found it. it seems that when there is no friendly name this will be the error:
org.apache.ws.security.WSSecurityException: The security token could not be authenticated or authorized
so to avoid that at least one certificate needs a name it can even be emtpy like this:
openssl pkcs12 -export -out keystore.p12 -inkey key.pem -in cert.pem -name "{CSR_Request_Finished}" -certfile certRest.pem -caname ""
above works but best is off course to do:
openssl pkcs12 -export -out keystore.p12 -inkey key.pem -in cert.pem -name "{CSR_Request_Finished}" -certfile certRest.pem -caname "cert one" -caname "cert intermediate" -caname "cert root" etc....
the diff is with no caname given you get this:
Bag Attributes: <No Attributes>
with an emtpy name you get this:
Bag Attributes
friendlyName:
you can view this info with this command:
openssl pkcs12 -info -in keystore.p12