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,
    Mike

    I 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

  • Jwsdp-1.4/xws-security/samples/simple/build.xml:108: wsdeploy failed

    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,
    Jake

    Hello 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 Batista

    Hi,
    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!
    George

    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

  • Jwsdp-1.4 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

  • Error:iaik.security.ssl.SSLCertificateException: Peer certificate rejected

    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

  • Clients connect to wifi with certificate that expires every month - correct way to handle expired certificates?

    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.

  • I was unable to reach my bank. Firefox said that "connection is untrusted" and that the Security Certification has expired. I contacted my bank and they said to call Firefox. Please help.

    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
    Magnus

    is 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