JWSDP xws-security validation of expired certificate
I'm using JWSDP 1.6, in SecurityEnvironmentHandler (server side) I have >
if (callbacks[i] instanceof CertificateValidationCallback) {
CertificateValidationCallback cb = (CertificateValidationCallback) callbacks;
cb.setValidator(new X509CertificateValidatorImpl());
and this X509CertificateValidatorImpl() looks like >
private class X509CertificateValidatorImpl implements
CertificateValidationCallback.CertificateValidator {
public boolean validate(X509Certificate certificate)
throws CertificateValidationCallback.CertificateValidationException {
try {
certificate.checkValidity();
} catch (CertificateExpiredException e) {
// e.printStackTrace();
throw new CertificateValidationCallback.CertificateValidationException(
"X509Certificate Expired", e);
} catch (CertificateNotYetValidException e) {
// e.printStackTrace();
throw new CertificateValidationCallback.CertificateValidationException(
"X509Certificate not yet valid", e);
...As input of validate(X509Certificate certificate) method is expired certificate. It's thrown CertificateValidationCallback.CertificateValidationException, but this exception is lost in other classes JWSDP. I have no src to debug it.
Secure SOAP message with this expired certificate is allowed to be OK.
I don't know where is problem, because I can't debug it. Any idea ? thx
... this problem is only in JWSDP 1.6 ... not in JWSDP 2.0
Similar Messages
-
JWSDP 1.5: Certificates for XWS-Security samples expired April 9
The digitial certificates supplied with the XWS-Security samples in JWSDP 1.5 (e.g., JWSDP_HOME/xws-security/etc/client-truststore.jks) expired April 9, 2005. The XWSS sample programs now fail because the certificates are invalid. Are newer versions of the truststores available to replace the existing truststores, or do I need reinstall JWSDP to get newer certificates?
Thanks,
MikeI am having the same problem. I tried creating my own RSA keys with the same aliases, self signing them and putting them into the key/trust stores but still get errors. What procedure is there to replace them? Included below are my steps for dropping the certs and adding in new self signed ones, that I tried.
Josh
keytool -delete -keystore server-keystore.jks -alias s1as -storepass changeit
keytool -delete -keystore client-truststore.jks -alias s1as -storepass changeit
keytool -genkey -keyalg RSA -alias s1as -keystore server-keystore.jks -dname "cn=Client" -keypass changeit -storepass changeit
keytool -selfcert -alias s1as -keystore server-keystore.jks -keypass changeit -storepass changeit
keytool -export -keystore server-keystore.jks -alias s1as -storepass changeit -file s1as
keytool -import -alias s1as -keystore client-truststore.jks -storepass changeit -file s1as
keytool -delete -keystore client-keystore.jks -alias xws-security-client -storepass changeit
keytool -delete -keystore server-truststore.jks -alias xws-security-client -storepass changeit
keytool -genkey -keyalg RSA -alias xws-security-client -keystore client-keystore.jks -dname "cn=Client" -keypass changeit -storepass changeit
keytool -selfcert -alias xws-security-client -keystore client-keystore.jks -keypass changeit -storepass changeit
keytool -export -keystore client-keystore.jks -alias xws-security-client -storepass changeit -file xws-security-client
keytool -import -alias xws-security-client -keystore server-truststore.jks -storepass changeit -file xws-security-client -
Hi everyone,
I am trying to deploy the simple sample for xws-security in the JWSDP 1.4 on redhat 9.0, I have done all the configurations as suggested by the tutorial and the readme file in the sample. But when I tried to run the sample by running "asant run-sample", I got a "wsdeploy failed" error. It looks like the following and happened at the "process-war" stage: (The earlier targets including "clean", "prepare", "gen-server", "compile-server", " set-web-inf", "raw-war" etc. work fine).
[snip]
process-war:
[echo] Running wsdeploy...
[wsdeploy] Exception in thread "main" java.lang.NoSuchMethodError: org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.<init>(Lorg/apache/xml/dtm/DTMManager;Ljavax/xml/transform/Source;ILorg/apache/xml/dtm/DTMWSFilter;Lorg/apache/xml/utils/XMLStringFactory;ZIZZ)V
[wsdeploy] at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM2.<init>(SAX2DTM2.java:1901)
[wsdeploy] at org.apache.xalan.xsltc.dom.SAXImpl.<init>(SAXImpl.java:767)
[wsdeploy] at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:324)
[wsdeploy] at org.apache.xalan.xsltc.dom.XSLTCDTMManager.getDTM(XSLTCDTMManager.java:267)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.getDOM(TransformerImpl.java:477)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:637)
[wsdeploy] at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:317)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.DeployTool.defineServletsAndListeners(DeployTool.java:553)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.DeployTool.run(DeployTool.java:255)
[wsdeploy] at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:43)
[wsdeploy] at com.sun.xml.rpc.tools.wsdeploy.Main.main(Main.java:22)
[wsdeploy] Command invoked: /work/nzw3/SUNWappserver/jdk/jre/bin/java -classpath /work/nzw3/SUNWappserver/lib/endorsed/dom.jar:/work/nzw3/SUNWappserver/lib/endorsed/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/endorsed/xalan.jar:/work/nzw3/SUNWappserver/lib/ant/lib/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/ant/lib/ant.jar:/work/nzw3/SUNWappserver/lib/ant/lib/xml-apis.jar:/work/nzw3/SUNWappserver/lib/ant/lib/optional.jar:/work/nzw3/SUNWappserver/lib/soapprocessor.jar:/work/nzw3/SUNWappserver/lib/jaxr-api.jar:/work/nzw3/SUNWappserver/lib/saaj-api.jar:/work/nzw3/SUNWappserver/lib/activation.jar:/work/nzw3/SUNWappserver/lib/security-plugin.jar:/work/nzw3/SUNWappserver/lib/jaxb-xjc.jar:/work/nzw3/SUNWappserver/lib/jax-qname.jar:/work/nzw3/SUNWappserver/lib/jhall.jar:/work/nzw3/SUNWappserver/lib/xmlsec.jar:/work/nzw3/SUNWappserver/lib/j2ee-svc.jar:/work/nzw3/SUNWappserver/lib/deployment/sun-as-jsr88-dm.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-sec.jar:/work/nzw3/SUNWappserver/lib/mail.jar:/work/nzw3/SUNWappserver/lib/appserv-admin.jar:/work/nzw3/SUNWappserver/lib/jaxb-impl.jar:/work/nzw3/SUNWappserver/lib/appserv-cmp.jar:/work/nzw3/SUNWappserver/lib/appserv-jstl.jar:/work/nzw3/SUNWappserver/lib/jaxb-libs.jar:/work/nzw3/SUNWappserver/lib/jwsdp-tools-lib/jax-qname.jar:/work/nzw3/SUNWappserver/lib/jwsdp-tools-lib/namespace.jar:/work/nzw3/SUNWappserver/lib/jaxr-impl.jar:/work/nzw3/SUNWappserver/lib/xercesImpl.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-spi.jar:/work/nzw3/SUNWappserver/lib/verifier/verifierhelp.jar:/work/nzw3/SUNWappserver/lib/xalan.jar:/work/nzw3/SUNWappserver/lib/appserv-upgrade.jar:/work/nzw3/SUNWappserver/lib/appserv-assemblytool.jar:/work/nzw3/SUNWappserver/lib/deployhelp.jar:/work/nzw3/SUNWappserver/lib/j2ee.jar:/work/nzw3/SUNWappserver/lib/xmldsig.jar:/work/nzw3/SUNWappserver/lib/commons-logging.jar:/work/nzw3/SUNWappserver/lib/saaj-impl.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-impl.jar:/work/nzw3/SUNWappserver/lib/appserv-tags.jar:/work/nzw3/SUNWappserver/lib/appserv-ext.jar:/work/nzw3/SUNWappserver/lib/relaxngDatatype.jar:/work/nzw3/SUNWappserver/lib/admin-cli.jar:/work/nzw3/SUNWappserver/lib/jaxrpc-api.jar:/work/nzw3/SUNWappserver/lib/jsf-api.jar:/work/nzw3/SUNWappserver/lib/jaxb-api.jar:/work/nzw3/SUNWappserver/lib/install/applications/__cp/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/__ds/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/__xa/jdbc.jar:/work/nzw3/SUNWappserver/lib/install/applications/jmsra/imqjmsra.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/cc.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admingui-jsp.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/framework.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/jato.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin-en.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/admin-xml.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/framework-en.jar:/work/nzw3/SUNWappserver/lib/install/applications/admingui/adminGUI_war/WEB-INF/lib/help.jar:/work/nzw3/SUNWappserver/lib/install/applications/samples.jar:/work/nzw3/SUNWappserver/lib/install/applications/com_sun_web_ui/WEB-INF/lib/registrationservlet.jar:/work/nzw3/SUNWappserver/lib/install/applications/jaxr-ra/jaxr-ra.jar:/work/nzw3/SUNWappserver/lib/commons-launcher.jar:/work/nzw3/SUNWappserver/lib/jsf-impl.jar:/work/nzw3/SUNWappserver/lib/sun-appserv-ant.jar:/work/nzw3/SUNWappserver/lib/appserv-rt.jar:/work/nzw3/SUNWappserver/lib/xsdlib.jar:/work/nzw3/j2sdk1.4.2_04/lib/tools.jar com.sun.xml.rpc.tools.wsdeploy.Main -keep -tmpdir /work/nzw3/jwsdp-1.4/xws-security/samples/simple/build/server -o /work/nzw3/jwsdp-1.4/xws-security/samples/simple/dist/securesimple.war /work/nzw3/jwsdp-1.4/xws-security/samples/simple/dist/simple-portable.war
BUILD FAILED
file:/work/nzw3/jwsdp-1.4/xws-security/samples/simple/build.xml:108: wsdeploy failed
If anyone has any idea about this problem, please let me know.
Many thanks,
JakeHello again,
I got progress today, but still have some errors for the simple sample in the xws-security . (I am running on Redhat 9.0 and with Sun Java System Application Server 8) Looks like the sending message is ok, but at the receiving message stage, I got the following errors when running "asant run-sample":
[snip]
run-sample:
[echo] Running the simple.TestClient program....
[java] Service URL=http://giga15.ncl.ac.uk:8080/securesimple/Ping
[java] Sep 8, 2004 1:14:19 AM com.sun.xml.wss.filter.DumpFilter process
[java] INFO: ==== Sending Message Start ====
[java] <?xml version="1.0" encoding="UTF-8"?>
[java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[java] <env:Header>
[java] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
[java] <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="Id4487442798885738858">MIIFKDCCBBCgAwIBAgICBl4wDQYJKoZIhvcNAQEEBQAwcDELMAkGA1UEBhMCVUsxETAPBgNVBAoT
[java] CGVTY2llbmNlMRIwEAYDVQQLEwlBdXRob3JpdHkxCzAJBgNVBAMTAkNBMS0wKwYJKoZIhvcNAQkB
[java] Fh5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMudWswHhcNMDQwMjEwMTQzMDUyWhcNMDUwMjA5
[java] MTQzMDUyWjBcMQswCQYDVQQGEwJVSzERMA8GA1UEChMIZVNjaWVuY2UxEjAQBgNVBAsTCU5ld2Nh
[java] c3RsZTEPMA0GA1UEBxMGTkVSZVNDMRUwEwYDVQQDEwxqYWtlIHpoZW5nd3UwgZ8wDQYJKoZIhvcN
[java] AQEBBQADgY0AMIGJAoGBAO7B3texMjuzdA6zT6/F/hx3U4a+iWglhNWptB3JerhHHu7El0HkWky0
[java] 9AzYVKZ7Y3n5qpgmSOe16a2MKySii5ud44DABj+3qkRBzkb/LDgNuF02X/XORbFbuZYEWwCHckZI
[java] xQ50vJpdxJQqLOwrhMP48RXNBzrdXo9iYfcWP5cnAgMBAAGjggJiMIICXjAMBgNVHRMBAf8EAjAA
[java] MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCA+gwLAYJYIZIAYb4QgENBB8WHVVLIGUt
[java] U2NpZW5jZSBVc2VyIENlcnRpZmljYXRlMB0GA1UdDgQWBBRlyb19GkybkmGa6QnQ9fPZ7mQ+NzCB
[java] mgYDVR0jBIGSMIGPgBQCOKsRo5aAiw3TFSsIpY4w2rLaqKF0pHIwcDELMAkGA1UEBhMCVUsxETAP
[java] BgNVBAoTCGVTY2llbmNlMRIwEAYDVQQLEwlBdXRob3JpdHkxCzAJBgNVBAMTAkNBMS0wKwYJKoZI
[java] hvcNAQkBFh5jYS1vcGVyYXRvckBncmlkLXN1cHBvcnQuYWMudWuCAQAwKQYDVR0SBCIwIIEeY2Et
[java] b3BlcmF0b3JAZ3JpZC1zdXBwb3J0LmFjLnVrMBkGA1UdIAQSMBAwDgYMKwYBBAHZLwEBAQEEMD0G
[java] CWCGSAGG+EIBBAQwFi5odHRwOi8vY2EuZ3JpZC1zdXBwb3J0LmFjLnVrL2NnaS1iaW4vaW1wb3J0
[java] Q1JMMD0GCWCGSAGG+EIBAwQwFi5odHRwOi8vY2EuZ3JpZC1zdXBwb3J0LmFjLnVrL2NnaS1iaW4v
[java] aW1wb3J0Q1JMMDwGCWCGSAGG+EIBBwQvFi1odHRwOi8vY2EtcmVuZXcuZ3JpZC1zdXBwb3J0LmFj
[java] LnVrL3JlbmV3Lmh0bWwwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDovL2NhLmdyaWQtc3VwcG9ydC5h
[java] Yy51ay9jZ2ktYmluL2ltcG9ydENSTDANBgkqhkiG9w0BAQQFAAOCAQEAgdN714aoC53Wef9JGaDD
[java] PDJkmgmwVbL8ZuovBpORFsgy2GOPgIdtw15qTQx1NFbsFqW2I7d/9AteeXAk3sUGUODOvq8loeYB
[java] iA+QofduwJ0VWO8TZ0e+7+J3cDQKbsukptRJd2L2W8PeCNPojCRkfiV/nT6BiF5yjh4Ui5e+pWGw
[java] t3oN1qFDZViCFOTiB6Koi0MB+cu47gOEIxBQfP8jTEyf/SSy4RzjI+7C1LpDYCZpO/jqXMb67j9b
[java] KdcmlWhMrzNOyRDM7A11rt5nBMABgRVAJsdBZIDevfKJ/kRGxUHGHqf8Pg+3qK22mNwMN8U2plr7
[java] TgORAx6aOn4EQP2AzA==</wsse:BinarySecurityToken>
[java] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[java] <ds:SignedInfo>
[java] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[java] <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[java] <ds:Reference URI="#Id5553294937503469412">
[java] <ds:Transforms>
[java] <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
[java] </ds:Transforms>
[java] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[java] <ds:DigestValue>AcRqiIoxfOWauZ/FDnng4D1C5WU=</ds:DigestValue>
[java] </ds:Reference>
[java] </ds:SignedInfo>
[java] <ds:SignatureValue>
[java] omVS7TF+IqESZuMcRdsFfet8INaU4J9Vall1oGaPMRoEkc9xks+YK2ew4nG7hSekITwJrQLx42hH
[java] Vb6HvEdWgsIrjOJslqQILQkYU7qdoptb6OEgY5lHQpjUJaTKNn4krsDXgpwZieQE45Gcu/zuP4eY
[java] v8yMhUwVUE8xHy+6dLs=
[java] </ds:SignatureValue>
[java] <ds:KeyInfo>
[java] <wsse:SecurityTokenReference>
[java] <wsse:Reference URI="#Id4487442798885738858" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
[java] </wsse:SecurityTokenReference>
[java] </ds:KeyInfo>
[java] </ds:Signature>
[java] </wsse:Security>
[java] </env:Header>
[java] <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id5553294937503469412">
[java] <ns0:Ping>
[java] <ns0:ticket>SUNW</ns0:ticket>
[java] <ns0:text>Hello !</ns0:text>
[java] </ns0:Ping>
[java] </env:Body>
[java] </env:Envelope>
[java] ==== Sending Message End ====
[java] Sep 8, 2004 1:14:23 AM com.sun.xml.wss.filter.DumpFilter process
[java] INFO: ==== Received Message Start ====
[java] <?xml version="1.0" encoding="UTF-8"?>
[java] <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
[java] <env:Body>
[java] <env:Fault>
[java] <faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ans1:InvalidSecurityToken</faultcode>
[java] <faultstring>Certificate validation failed</faultstring>
[java] </env:Fault>
[java] </env:Body>
[java] </env:Envelope>
[java] ==== Received Message End ====
[java] Sep 8, 2004 1:14:23 AM com.sun.xml.wss.filter.ProcessSecurityHeaderFilter process
[java] WARNING: Message does not contain wsse:Security header
[java] Exception in thread "main" javax.xml.rpc.soap.SOAPFaultException: Certificate validation failed
[java] at com.sun.xml.rpc.client.StreamingSender._raiseFault(StreamingSender.java:515)
[java] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:294)
[java] at simple.PingPort_Stub.ping(PingPort_Stub.java:80)
[java] at simple.TestClient.main(TestClient.java:37)
[java] Java Result: 1
I don't know if I have configured anything wrong. Basically, i just want to sign the outgoing soap message with my own p12 format certificate, hence I have chosen the following in the $JWSDP_HOME/xws-security/samples/simple/build.properties :
client.security.config=config/sign-client.xml
server.security.config=config/dump-server.xml
Also, according to the last section of the jWSDP release notes at http://java.sun.com/webservices/docs/1.4/ReleaseNotes.html#KnownIssues
I added these two changes,
1. In the <jwsdp.home>/xws-security/samples/buildconfig/sjsas-config.xml file, delete the original .... app.classpath element definition and replace it with the following definition:
<path id="app.classpath">
<fileset dir="${sjsas.home}/lib/endorsed">
<include name="dom.jar"/>
</fileset>
<fileset dir="${sjsas.home}/lib">
<include name="*.jar"/>
</fileset>
<fileset dir="${javahome}/lib">
<include name="tools.jar"/>
</fileset>
</path>
2. In the <as.home>/domains/domain1/config/server.policy file, add the following configurations to the server.policy file, for the securesimple sample and pingservice samples, respectively.
// These permissions apply to securesimple webapp grant codeBase "file:${com.sun.aas.instanceRoot}/applications/j2ee-modules/securesimple/WEB-INF/-" {
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
permission javax.security.auth.AuthPermission "getSubject";
permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential * \"*\"","read";
permission java.security.SecurityPermission "putProviderProperty.BC";
Moreover, has the sent message really been signed correctly? how can I tell the message has been signed by my own certificate? I have done the following:
1. In the $JWSDP_HOME/xws-security/samples/simple/config/sign-client.xml, change to
<xwss:SecurityConfiguration
xmlns:xwss="http://com.sun.xml.wss.configuration" dumpMessages="true">
<xwss:Sign/>
</xwss:SecurityConfiguration>
2. In the $JWSDP_HOME/xws-security/samples/simple/config/build.xml, change to something like the following in the run-sample target,
<sysproperty key="javax.net.ssl.keyStore" value="/work/nzw3/jakenew.p12"/>
<sysproperty key="javax.net.ssl.keyStorePassword" value="jake"/>
<sysproperty key="javax.net.ssl.keyStoreType" value="pkcs12"/>
I didn't change anything about truststore.
What was the problem? What have I done wrong?
Many thanks,
Jake -
Sun.security.validator.ValidatorException: No trusted certificate found
Hello,
I am using Java 1.6.0_04 (JBoss-4.2.2.GA application). My application implements a WS client which needs to integrate with an external Web Service. This communication needs to be handled through https.
I have created a jks keystore with the server certificate, and passed its details to JBoss through the System Properties:
-Djavax.net.ssl.trustStore=/Path-to-file -Djavax.net.ssl.trustStorePassword=password On my development environment I can call the Web Service correctly.
Although, on the production environment, I am getting the following exception:
javax.xml.ws.WebServiceException: java.io.IOException: Could not transmit message
at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:317)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:255)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:164)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
at $Proxy171.send(Unknown Source)
at com.xpto.integration.SmsHelper.send(SmsHelper.java:57)
at com.xpto.services.sms.SMSSenderServiceMBean.run(SMSSenderServiceMBean.java:106)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Could not transmit message
at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:204)
at org.jboss.ws.core.client.SOAPRemotingConnection.invoke(SOAPRemotingConnection.java:77)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:337)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243)
... 6 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:
333)
at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.ws.core.client.RemotingConnectionImpl.invoke(RemotingConnectionImpl.java:183)
... 9 more
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No truste
d certificate found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:975)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:405)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLCo
nnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:832)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:23
0)
at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:
275)
... 14 more
Caused by: sun.security.validator.ValidatorException: No trusted certificate found
at sun.security.validator.SimpleValidator.buildTrustedChain(SimpleValidator.java:304)
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:107)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:2
09)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:2
49)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:954)
... 26 more Both systems are configured with the same JBoss, JVM, ...
The certificate details are:
Owner=
CN=*...., OU=..., O=..., L=..., ST=..., C=PT
Issuer=
CN=..., O=..., C=PT
Version=3
Serial Number=BC81A81843E26C2597CD10354588F61E
Valid From=Monday, 3 March 2008 18:50
Valid Until=Tuesday, 3 March 2009 18:50
Signature Algorithm=SHA1withRSA
Fingerprints=
MD5: 0A:A6:89:92:A4:CF:17:74:7C:4E:20:63:6B:81:AE:85
SHA1: 35:01:74:8C:35:AB:9F:02:7B:23:3F:15:5E:73:C6:4D:DD:BB:C0:7A
Key Usage= critical
List:
. digitalSignature
. keyEncipherment
. dataEncipherment
. keyAgreement
Extended Key Usage= none
On production I have also tried adding the following properties:
-Djavax.net.ssl.keyStore=/Path-to-file -Djavax.net.ssl.keyStorePassword=password But I still get the error.
Any one has any hint for this problem? Is there any property which I can define to ignore untrusted certificates?
Any help would really be welcome.
Thanks in advance.
Best regards,
Victor BatistaHi,
Thanks for your prompt reply.
I have also tried to add all the chain of certificates on my truststore, although I get the exception:
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Fri Mar 07 12:54:22 WET 2008
at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:256)
at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:570)
at sun.security.validator.SimpleValidator.engineValidate(SimpleValidator.java:123)
at sun.security.validator.Validator.validate(Validator.java:218)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:126)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:209)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:954)
... 26 moreAnd all the certificates are valid.
I really don't understand what is going on.
Can I Ignore expired certificates? Any property?
When I use -Djavax.net.ssl.trustStore pointing to my keystore, will cacerts be also used?
Do I need to import all the certificates in the chain of the server, or the top most is sufficient?
The server where I am having the problem has limited connectivity. It should have connectivity to the issuers of the certificates, in order to validate them, or not?
Thanks in advance,
Victor -
Timestamped document with expired certificate - not validating
Hi,
I have a document that was timestamped and certified on 2010/11/23 15:32:16 -03'00'. The timestamp certificate is still valid, but the certifier's certificate expired on 2010/12/11 07:00:00 -03'00'.
The Reader can't validate this certificate, eventhough the Security configuration says that it should use the "secure time" and accept expired timestamps.
In "Signature Properties" it says:
The signer's identity is unknown because it has expired or is not yet valid.
In "Certificate Viewer" it says:
The selected certificate has errors: Not time valid
Shouldn't the validation use the timestamp as a source for time validation?
Thanks!!
-RCT.Hi Melvin,
First check to see if the certificate is in the store
PowerShell: Get-ChildItem cert:\LocalMachine\My\ to list the certs in the store
Screenshot from my desktop
Cheers,
-Ivan
-Ivan -
JWSDP 1.6 xws-security Simple fails with "block not properly padded"
Environment:
- Windows 2000
- Tomcat50-jwsdp
- JAVA_HOME=C:/Progra~1/Java/jdk1.5.0_05
- Security environment handler: SecurityEnvironmentHandler.java supplied with JWSDP 1.6 (Hello, Ron!)
I get the following in the Tomcat Window:
==== Received Message End ====
Nov 13, 2005 10:38:56 AM com.sun.org.apache.xml.internal.security.encryption.XMLCipher decryptKey
INFO: Decryption of key type http://www.w3.org/2001/04/xmlenc#tripledes-cbc OK
Nov 13, 2005 10:38:56 AM com.sun.xml.wss.impl.apachecrypto.DecryptionProcessor decryptElementWithCipher
SEVERE: WSS_ENC0004: Exception [ Given final block not properly padded ] while trying to decrypt message
Nov 13, 2005 10:38:56 AM com.sun.xml.wss.impl.filter.DumpFilter process
INFO: ==== Sending Message Start ====
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/enco
ding/" xmlns:ns0="http://xmlsoap.org/Ping" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.or
g/2001/XMLSchema-instance">
<env:Body>
<env:Fault>
<faultcode xmlns:ans1="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ans1:Fail
edCheck</faultcode>
<faultstring>Unable to decrypt message</faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
==== Sending Message End ====
Please help!
GeorgeHi, I got the xws-security/samples/simple application
working successfully with my own keystores. I have 2
questions regarding this sample application.
1) When running the application with the
encrypt-server.xml and encrypt-client.xml
configuration, why is it necessary to import the
client's certificate into the server's truststore and
the server's certificate into client's truststore when
their certificates have already been signed by a
trusted root CA (e.g. Verisign), whose certificate is
in both truststores? Shouldn't their certificates
containing their public keys get automatically
exchanged during the connection request? It's a pain
to publish a web service and expect a manual public
certificate import for each client wanting to use the
service.Certificates are sent only when the keyReferenceType is "Direct" which is the default. It's possible that our code is checking the certificate sent with one found in the KeyStore, but a quick scan of the code doesn't show it. If that's what's happening it's a bug. All of the other key reference strategies send only a referece to the sender's certificate in which case the reciever must have a copy of that certificate in its keystore.
2) I use Tomcat to run the sample application and did
set up the SSL connector to point to the keystores.
When the client connects to the server, it uses a
http endpoint not https. I'm aware that htpps is
needed for SSL support but not clear on where does
https come into play during the client's
request/server's response process.We share the SSL keystore so that certificates don't have to be stored in more than one place. The functionality of XWS-Security and SSL is logically the same so it make sense to use the same keystore. XWS-Security operates completely separately from the transport and never knows whether HTTPS is in use or not.
Phil Goodwin
Technical Lead
XWS-Security -
Hi, I got the xws-security/samples/simple application working successfully with my own keystores. I have 2 questions regarding this sample application.
1) When running the application with the encrypt-server.xml and encrypt-client.xml configuration, why is it necessary to import the client's certificate into the server's truststore and the server's certificate into client's truststore when their certificates have already been signed by a trusted root CA (e.g. Verisign), whose certificate is in both truststores? Shouldn't their certificates containing their public keys get automatically exchanged during the connection request? It's a pain to publish a web service and expect a manual public certificate import for each client wanting to use the service.
2) I use Tomcat to run the sample application and did set up the SSL connector to point to the keystores. When the client connects to the server, it uses a http endpoint not https. I'm aware that htpps is needed for SSL support but not clear on where does https come into play during the client's request/server's response process.Hi, I got the xws-security/samples/simple application
working successfully with my own keystores. I have 2
questions regarding this sample application.
1) When running the application with the
encrypt-server.xml and encrypt-client.xml
configuration, why is it necessary to import the
client's certificate into the server's truststore and
the server's certificate into client's truststore when
their certificates have already been signed by a
trusted root CA (e.g. Verisign), whose certificate is
in both truststores? Shouldn't their certificates
containing their public keys get automatically
exchanged during the connection request? It's a pain
to publish a web service and expect a manual public
certificate import for each client wanting to use the
service.Certificates are sent only when the keyReferenceType is "Direct" which is the default. It's possible that our code is checking the certificate sent with one found in the KeyStore, but a quick scan of the code doesn't show it. If that's what's happening it's a bug. All of the other key reference strategies send only a referece to the sender's certificate in which case the reciever must have a copy of that certificate in its keystore.
2) I use Tomcat to run the sample application and did
set up the SSL connector to point to the keystores.
When the client connects to the server, it uses a
http endpoint not https. I'm aware that htpps is
needed for SSL support but not clear on where does
https come into play during the client's
request/server's response process.We share the SSL keystore so that certificates don't have to be stored in more than one place. The functionality of XWS-Security and SSL is logically the same so it make sense to use the same keystore. XWS-Security operates completely separately from the transport and never knows whether HTTPS is in use or not.
Phil Goodwin
Technical Lead
XWS-Security -
Hi,
I am getting error com.sap.engine.interfaces.messaging.api.exception.MessagingException:
iaik.security.ssl.SSLCertificateException: Peer certificate rejected by ChainVerifier
When i test for digital signing and encryption using soap receiver CC
we passed all the values for soap CC
Created key store view and in that view I have generated private certificate and generated CSR using SAP CA(test ssl for 8 weeks) for the private key and also imported public key for encryption given by reciver
When i test i get the error message
I check certificates validity dates
I restarted java engine and ICM
I added the public key in trusted CA in NWA
I re created the view and added the certifcates
still the same error
how and where to check to check IAIK in NWA and how to deploy it in java engine using NWA, we are using PI7.11 (no VA)
any suggestions?Hi,
The main causes for this kind of problem are:
1. The correct server certificate could not be present in the TrustedCA keystore view of NWA. Please ensure you have done all the steps described in the URL below:
Security Configuration at Message Level
http://help.sap.com/saphelp_nwpi71/helpdata/EN/ea/c91141e109ef6fe1000000
0a1550b0/frameset.htm
2. The server certificate chain contains expired certificate. Check for it and if it's the case renew it or extend the validation.
3. The certificate chain was not in correct order. Basically the server certificate chain should be in order
Own->Intermedite->Root. To explain in detail, if your server certificate is A which is issued by an intermediate CA B and then B's certificate is issued by the C which is the root CA (having a self signed certificate).
Then your certificate chain contains 3 elements A->B->C. So you need to have the right order of certificate in the chain. If the order is B first followed by A followed by C, then the IAIK library used by PI cannot verify the server as trusted. Generate the certificate in the right order and then import this certificate in the TrustedCA keystore view and try again.
4. If the end point of the SOAP Call(Server) is configured to accept a client certificate(mandatory), then make sure that it is configured correctly in the SOAP channel and it is also within validity period.
(This certificate is the one which is sent to Server for Client authentication)
As a resource, you may need to create a new SSL Server key.
The requirement from SAP SSL client side is that the requested site has to have certificate with CN equal to the requested site. I mean if I request URL X then the CN must be CN=X.
In other words, the CN of the certificate has to be equal to the URL in the ftp request. This can be the IP address or the full name of the host.
Request the url with the IP of the SSL Server and the certificate to be with CN = IP of the server.
In any other case the SSL communication will not work.
Regards,
Caio Cagnani -
Xws-security returns always HTTP 200
Hi,
I am using libraries of JWSDP 2.0, jaxws and xws-security.
My web service was generated from a WSDL schema and works so
far fine. I need to secure the transportation with a xml signature.
For that I am using the xws libraries.
My problem is that xws-security and jaxws returns always HTTP 200. I
would expect a negative HTTP status code if the signature validation
fails, such as HTTP 401 or HTTP 500 or whatever.
Is this a bug or any idea what my problem might be ?
Thanks,
Simel.Hi,
I am using libraries of JWSDP 2.0, jaxws and xws-security.
My web service was generated from a WSDL schema and works so
far fine. I need to secure the transportation with a xml signature.
For that I am using the xws libraries.
My problem is that xws-security and jaxws returns always HTTP 200. I
would expect a negative HTTP status code if the signature validation
fails, such as HTTP 401 or HTTP 500 or whatever.
Is this a bug or any idea what my problem might be ?
Thanks,
Simel. -
XWS-Security, modify namespace location
Hi,
we are using JWSDP 2.0 and xws-security for sign our SOAP message.
We need to save the payload and the signature in a database and need
to to validate it on some occations. So have to save the <Signature>
Tag. The Problem is it is not valid due to missing namespace
declarations.
Is it possible to modify the placing of namespace, or to modifiy the
defining of namespaces as default ns ?
SECURITY INFO GENERATED BY XWSS:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/w...">
---CUT HERE BEGIN---
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo> ... </ds:SignedInfo>
<ds:SignatureValue> ... </ds:SignatureValue>
<ds:KeyInfo>
<wsse:SecurityTokenReference
wsu:Id="XWSSGID-1168439423391-1452886180"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<ds:X509Data> ... </ds:X509Data>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
---CUT HERE END---
</wsse:Security>
===> IF WE CUT THE SINGATURE PART, THE NS-PREFIX wsse IS NOT BOUND
A BETTER SOLUTION WOULD BE:
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/w...">
---CUT HERE BEGIN---
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo> ... </SignedInfo>
<SignatureValue> ... </SignatureValue>
<KeyInfo>
<SecurityTokenReference
xmlns="http://docs.oasis-open.org/w...">
<X509Data xmlns="http://www.w3.org/2000/09/xmldsig#"> ... </X509Data>
</SecurityTokenReference>
</KeyInfo>
</Signature>
---CUT HERE END---
</wsse:Security>
Any idea how to resolve this problem ?
Thanks for help.
Simil.no it is not possible to change the namespace
-
Hi all
I'm sorry if this is the wrong forum to ask this question. Also my knowledge in this area is somewhat limited, which I why I need your help :-)
We use wireless networks primarily in my company for all our clients and use a certificate to authenticate to the network. This certificate expires after 1 month and we automatically renew them 1 week before expiry. Relatively often we have users that
are not connected to the network for a few weeks or more and then the certificate expires before being renewed. Then we have to connect them to the wired network to get the certificate updated, so they can connect to the wireless network again.
What is the correct approach to solve this issue? We feel extending the life of the certificate would be a too big security compromise. Is there some way you could automatically allow an expired certificate briefly with the sole purpose of renewing the certificate?
Or how would you normally resolve this issue?
Thanks for any help/knowledge you can provide :-)> Setting the validity period that high, means that the certificate could be cracked before expiry.
then you should be scary of CAs which validity is 10 or more years. And they use the same cryptography as end-entity certificates (key length and signature algorithms). It is a paranoya. Just make sure if client certificates use at least 2048 bit long
keys and use SHA1 (or better) signature algorithm. In this case there is a little chance that certificate will be successfully cracked in 2 years.
If there is an evidence (or indications) of client private key compromise -- immediately revoke the certificate and publish new CRL ASAP. You cannot protect clients from key compromise by using short-living certificates, because key compromise is ususally
achieved by gaining a control over the private key (malware on client computer). Therefore, there is nothing wrong in issuing client certificates with 1 or 2 year validity.
My weblog: en-us.sysadmins.lv
PowerShell PKI Module: pspki.codeplex.com
PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
Check out new: SSL Certificate Verifier
Check out new:
PowerShell FCIV tool. -
When attempting to go online to my bank, I received a message of "connection is untrusted". Security Certification has expired as of last night. My banker said that this is a problem with Firefox.
Gwen Smith [email protected]It appears their security certificate is set to expire 02/25/2012. You can check this on one of their secure pages by clicking the Site Identity Button.
*https://support.mozilla.com/en-US/kb/Site+Identity+Button
*http://www.dria.org/wordpress/archives/2008/05/06/635/
Is the calendar/clock on your system set correctly? Right-click the calendar/clock at the right end of the Windows Taskbar and choose Adjust Date/Time, if necessary. You can also access the Adjust Date/Time in Windows XP via Start > Settings > Control Panel > Date and Time. See https://support.mozilla.com/en-US/kb/Secure%20Connection%20Failed#w_certificate-will-not-be-valid-until-date
If your system is not keeping correct Date and Time, you may need a new "coin" battery on your motherboard.
'''If this reply solves your problem, please click "Solved It" next to this reply when <u>signed-in</u> to the forum.'''
Not related to your question....
Remove My Web Search; it is considered malware/spyware:
*http://www.safer-networking.com/removemywebsearch.php
#[http://www.pchell.com/support/mywebsearch.shtml PC Hell: My Web Search Removal Instructions]
*http://helpint.mywebsearch.com/intlinfo/help/toolhelp.jhtml#q3
*Also see: http://kb.mozillazine.org/Uninstalling_toolbars
Also not related to your question...
You need to update some plug-ins:
*Plug-in check: https://www-trunk.stage.mozilla.com/en-US/plugincheck/
*Shockwave Flash (Adobe Flash or Flash): [https://support.mozilla.com/en-US/kb/Managing%20the%20Flash%20plugin#w_updating-flash Updating Flash in Firefox] -
Can I trust an expired certificate?
Hi,
is there any setting that will let me trust an expired certificate? I'm communicating with a server that has an unsigned expired certificate. The funny thing is that this behavior seems to has changed on different jvm-versions, on one of my client-machines I'm running a jvm version 1.5.0_06-b05, which is accepting the expired certificate. On a different client I'm running jvm version 1.5.0_07-b03, and this version is NOT accepting the expired certificate, I'm using the exact same trust store file!?
Of course the solution is to install a valid certificate on the server but that is out of my control...
Regards
Magnusis there any setting that will let me trust an expired certificate?That's a contradiction in terms. The person who signed it, or self-signed it, gave it an expiry date beyond which you shouldn't trust it. So you shouldn't trust it.
Of course the solution is to install a valid certificate on the server but that is out of my control...It probably isn't out of your control at all. If it's a third party, complain to their customer service or IT department. If it's internal to your organization, ditto, and in both cases raise it as a major security risk for the project - get it elevated to project manager level or beyond. Be the squeaky wheel that gets the grease. -
ISE 1.2 / WLC 5508 EAP-TLS expired certificate error, but wireless still working
Hi I have a customer that we've deployed ISE 1.2 and WLC 5508s at. Customer is using EAP-TLS with and everything appears to setup properly. Users are able to login to the network and authenticate, however, frequently, I'm getting the following error in ISE authentication logs:
12516 EAP-TLS failed SSL/TLS handshake because of an expired certificate in the client certificates chain
OpenSSL messages are:
SSL alert: code=Ox22D=557 : source=local ; type=fatal : message="X509
certificate ex pi red"'
4 727850450.3616:error.140890B2: SS L
rOYbne s: SSL 3_ G ET _CL IE NT _CE RT IF ICAT E:no ce rtific ate
relurned: s3_ srvr.c: 272 0
I'm not sure if this is cosmetic or if this is something that I should be tracking down. System isn't in full production yet, but every client seems to be working and there is no expired cert in the chain. Any ideas what to check?Hello Dino,
thanks very much for your reply.
The client uses a machine-certificate, the PKI is not a microsoft one, but a third party PKI. The certificate is fresh and valid, the root-cert is installed and checked to be validated against it for the login.
Clock is correct too. The same setup works flawlessly in Windows 7 and XP.
EKU is set on the certificate (1.3.6.1.5.5.7.3.2)
I suspect the cert-setup itself, but don't get a clue where this might stuck...
Björn -
Anyconnect VPN - Expired certificate causing Java error
Hello,
Since April 4th 2015 Java has been blocking the process of installing AnyConnect via web-deployment (see attached screenshot). It indicates there is an expired certificate with these details:
Issuer CN=VeriSign Class 3 Code Signing 2010 CA,
OU=Terms of use at https://www.verisign.com/rpa (c)10,
OU=VeriSign Trust Network,
O="VeriSign, Inc.",
C=US
Validity [From: Wed Jan 02 19:00:00 EST 2013,
To: Sat Apr 04 19:59:59 EDT 2015] <-----------------------------
Subject CN="Cisco Systems, Inc.", <-----------------------------
OU=Digital ID Class 3 - Microsoft Software Validation v2,
O="Cisco Systems, Inc.",
L=Boxborough,
ST=Massachusetts,
C=US
This certificate is not seen when entering 'show crypto ca cert' on the ASA -- it is NOT our certificate, as it is issued to "Cisco Systems, Inc", and it has clearly expired.
We are running the ASA software 9.1.6 and this behavior happens (at least) with the three latest versions of Java.
Is anyone else having this issue? Is there anything that can be done (server-side) to resolve this?
Thanks in advance...I think it is possible to use same digital certificate. You can specify whether you want users to authenticate using AAA with a username and password or using a digital certificate (or both). When you configure certificate-only authentication, users can connect with digital certificate and are not required to provide a user ID and password.
Maybe you are looking for
-
Can anyone advise how to close apps with the new iOS? I have multiple open and cannot close them
-
I am a Captivate novice, using version 5 on Mac. I am thrilled that my project can be published as a pdf. Everything works great except the interactive buttons, which are supposed to open various small pdfs. I placed the linked documents in the same
-
Facetime with ipod touch, no video showing up
I'm using face time to call my mom. My mom can see me, but I don't see her. I can however, see myself. This is also inconsistent, sometimes it works, other times it doesn't.
-
I have a T400 and I'm thinking the MOBO is bad, it boots up then after a little while (5-20 min) it will freeze up, then after a few minutes it shuts off on it's own and reboots. Whewn it starts the screen goes black then after a few minutes it reboo
-
What shall I do with my set up and new HD?
I just bought a new 250GB USB 7200RPM HD....finally! I have often gotten the "HD too slow" error with Logic Express. Should I just move the entire OS and all Logic Express software and components over to the new drive? Use Logic Express on the new HD