[solved] weechat client certificates broken?

Is anybody successfully using weechat to authenticate to OFTC by sending a cert? I'm seeing nonsense behavior when I try.
I'm following the weechat instructions here: http://www.weechat.org/files/doc/stable … rtificates and also looking at OFTC's doc here: http://www.oftc.net/oftc/NickServ/CertFP
Verification via CA works fine (observe the 3rd line down):
20:12:26 oftc | irc: connecting to server irc.oftc.net/6697 (SSL)...
20:12:26 oftc | gnutls: connected using 2048-bit Diffie-Hellman shared secret exchange
20:12:26 oftc | gnutls: peer's certificate is trusted
20:12:26 oftc | gnutls: receiving 4 certificates
20:12:26 oftc | - certificate[1] info:
20:12:26 oftc | - subject `CN=oxygen.oftc.net', issuer `O=Open and Free Technology Community,OU=certification authority for irc,CN=irc.ca.oftc.net,[email protected]', RSA key 2048 bits, signed using RSA-SHA, activated
| `2009-08-07 14:31:48 UTC', expires `2010-08-07 14:31:48 UTC', SHA-1 fingerprint `852cb9bbab6ae5c5c3d4a745e255b175006e7314'
20:12:26 oftc | - certificate[2] info:
20:12:26 oftc | - subject `O=Open and Free Technology Community,OU=certification authority for irc,CN=irc.ca.oftc.net,[email protected]', issuer `O=Open and Free Technology Community,OU=Certification
| Authority,CN=ca.oftc.net,[email protected]', RSA key 2048 bits, signed using RSA-SHA, activated `2008-05-25 00:10:59 UTC', expires `2013-05-24 00:10:59 UTC', SHA-1 fingerprint
| `e45b2de35faec3e999209e34f7ce4c05b6adb73c'
20:12:26 oftc | - certificate[3] info:
20:12:26 oftc | - subject `O=Open and Free Technology Community,OU=Certification Authority,CN=ca.oftc.net,[email protected]', issuer `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
| Interest,OU=hostmaster,CN=Certificate Authority,[email protected]', RSA key 2048 bits, signed using RSA-SHA, activated `2008-05-24 23:53:25 UTC', expires `2013-05-23 23:53:25 UTC', SHA-1 fingerprint
| `27361360dd639f5ee74b07468345516fc0f052f1'
20:12:26 oftc | - certificate[4] info:
20:12:26 oftc | - subject `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,[email protected]', issuer `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
| Interest,OU=hostmaster,CN=Certificate Authority,[email protected]', RSA key 4096 bits, signed using RSA-SHA, activated `2008-05-13 08:07:56 UTC', expires `2018-05-11 08:07:56 UTC', SHA-1 fingerprint
| `af70884383820215cd61c6bcecfd3724a990431c'
But then, when weechat tries to use my cert and key to do mutual auth, it fails. Notice that it claims to find a cert with the same subject as OFTC's CA in my client.pem file, which is nonsense:
20:12:26 oftc | gnutls: sending one certificate
20:12:26 oftc | - client certificate info (/home/ataraxia/.weechat/ssl/client.pem):
20:12:26 oftc | - subject `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public Interest,OU=hostmaster,CN=Certificate Authority,[email protected]', issuer `C=US,ST=Indiana,L=Indianapolis,O=Software in the Public
| Interest,OU=hostmaster,CN=Certificate Authority,[email protected]', RSA key 4096 bits, signed using RSA-SHA, activated `2008-05-13 08:07:56 UTC', expires `2018-05-11 08:07:56 UTC', SHA-1 fingerprint
| `af70884383820215cd61c6bcecfd3724a990431c'
20:12:26 oftc =!= | irc: TLS handshake failed
20:12:26 oftc =!= | irc: error: Insufficient credentials for that request.
I've double- and triple-checked that the contents of client.pem (MY cert and key, and nothing to do with OFTC or SPI) are correct.
What is going on here? Is weechat really using the wrong creds to authenticate me? (If that's so, at least it explains the "Insufficient credentials" error, as of course I don't have the key for SPI's CA.) Does this work for other people? Google finds no complaints of such a bug.
I'm quite experienced with X509, so you don't need to explain things in baby terms here.
Last edited by ataraxia (2010-08-12 14:18:55)

gour wrote:I've tried on #weechat, but no response...it's quite dead there.
Weechat dev returned from vacation and tried to reproduce problem without success yesterday.
Then I found out what's wrong...weechat uses openssl-1.0.0.a on Archlinux which, somehow, produces ucompatible cert which weechat cannot read properly.
After creating cert with openssl-0.9.80, everything is fine now.
Sincerely,
Gour

Similar Messages

SOAP Receiver Adapter problem (client certificate required)

My Scenario is similar to described in https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/3721. [original link is broken] [original link is broken] [original link is broken] I have two PI servers running on one machine. I am trying to post message HTTPS with Client authentication via SOAP adapter from one PI system to SOAP adapter of other PI server. I have done the following configuration.
PI Server AXD - (Client) - Receiver SOAP adapter
PI Server AXQ - (Server) - Sender SOAP Adapter.
Steps in AXD
1. I have created a certificate of AXD in the service_ssl view of key storage.
2. I have imported the AXQ public certificate in to AXD in the TrustedCAs of Key storage
Steps in AXQ
1. I have created a certificate of AXQ in the service_ssl view of key storage.
2. I have imported the AXD public certificate in to AXQ in the TrustedCAs of Key storage.
3. I have created a user in AXQ and assigned the certificate of AXD under usermangement in Security provider to this user.
4. I have added the AXD certificate under Client Authentication tab with require client certificate option checked in the SSL Provider.
5. I have assigned the user created in AXQ in the step above to the Sender Agreement.
Now when I post message from AXD with Configure Client Authentication checked (Here I have selected the certificate of AXD and view as service_ssl) I am getting the following error.
Exception caught by adapter framework: SOAP: response message contains an error XIServer/UNKNOWN/ADAPTER.JAVA_EXCEPTION - java.security.AccessControlException: client certificate required at com.sap.aii.af.mp.soap.ejb.XISOAPAdapterBean.process(XISOAPAdapterBean.java:884) at com.sap.aii.af.mp.module.ModuleLocalLocalObjectImpl0_3
Any pointer to solve this problem is highly appreciated.
Thanks
Abinash

Hi Hemant,
I have couple of questions. Why do we need to import certificate for SOAP WS-Security and from where I can get it?
As far as my scenario goes I am not using message level security.
Secondly what do you mean by TRUSTED/WebServiceSecurity? I don't see any such view inside the Key Storage. I can see a view named just WebServiceSecuity though.
Also I don't have a decentralized adapter installation rather I have two separate PI instances having their own central adapter engine.
Abinash

How to load a client certificate into a servlet to access a Web Service

Hi,
I am having the following problem:
I am trying to use a Web Service client (Axis) within a servlet running under
WebLogic 8.1.
I would like to have mutual SSL-based authentication between the client and the
server hosting the Web Service. Thus, my client has to send a certificate to the
server.
My problem is: how to get the certificate into the request? I know that, for example,
the HttpsURLConnection class of WebLogic has a loadIdentity method. But I can't
use this class.
Is there any other method to make sure that SSL requests use my client certificates?
By the way, I am receiving the following error message from the server:
<Apr 13, 2004 5:35:10 PM EEST> <Debug> <TLS> <000000> <Required peer certificate
s not supplied by peer>
<Apr 13, 2004 5:35:10 PM EEST> <Warning> <Security> <BEA-090508> <Certificate
ch
ain received from 127.0.0.1 - 127.0.0.1 was incomplete.>
Anyone has an idea?
Thanks for any hints,
Zoltan Schreter
Nokia

Hi all,
I have solved this problem basically by using weblogic's SSLSocketFactory instead
of the default one used by Axis. I created a custom HttpSender (MyHttpSender)
which uses this Factory. I then created a custom Config class which I pass to
the constructor of Service. The Config class looks like this:
public class MyConfig extends SimpleProvider {
* Constructor - deploy client-side basic transports.
public MyConfig() {
deployTransport("java", new SimpleTargetedChain(new JavaSender()));
deployTransport("local", new SimpleTargetedChain(new LocalSender()));
deployTransport("http", new SimpleTargetedChain(new MyHttpSender()));
The relevant code within MyHttpSender looks something like this:
SSLClientInfo sslinfo = new SSLClientInfo();
File ClientKeyFile = new File("C:/certificates/testkey.pem");
File ClientCertsFile = new File("C:/certificates/testcert.pem");
InputStream[] ins = new InputStream[2];
ins[0] = new FileInputStream(ClientCertsFile);
ins[1] = new FileInputStream(ClientKeyFile);
String pwd = "mykeypass";
sslinfo.loadLocalIdentity(ins[0], ins[1], pwd.toCharArray());
javax.net.SocketFactory sockf = weblogic.security.SSL.SSLSocketFactory.getJSSE(sslinfo);
sock = sockf.createSocket(host, port) ;
By the way, this change also solved the other problem I posted about (not being
able to tunnel through the https proxy).
Cheeers,
Zoltan Schreter
Nokia
"Tony" <TonyV> wrote:
Which API's are you currently using for the SSL communication in the
client
side?
Tony
"Zoltan Schreter" <[email protected]> wrote in message
news:[email protected]...
Hi,
I am having the following problem:
I am trying to use a Web Service client (Axis) within a servlet runningunder
WebLogic 8.1.
I would like to have mutual SSL-based authentication between the clientand the
server hosting the Web Service. Thus, my client has to send a certificateto the
server.
My problem is: how to get the certificate into the request? I knowthat,
for example,
the HttpsURLConnection class of WebLogic has a loadIdentity method.But I
can't
use this class.
Is there any other method to make sure that SSL requests use my clientcertificates?
By the way, I am receiving the following error message from the server:
<Apr 13, 2004 5:35:10 PM EEST> <Debug> <TLS> <000000> <Required peercertificate
s not supplied by peer>
<Apr 13, 2004 5:35:10 PM EEST> <Warning> <Security> <BEA-090508><Certificate
ch
ain received from 127.0.0.1 - 127.0.0.1 was incomplete.>
Anyone has an idea?
Thanks for any hints,
Zoltan Schreter
Nokia

No client certificate available, sending empty certificate message

Dear Experts,
    I am trying to establish SSL client certificate connection to external partner. What puzzles me is that the certificate is not picked up by SAP PI. The intermediate and root CA for the partner are OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,OU=VeriSign International Server CA - Class 3,OU=VeriSign, Inc.,O=VeriSign Trust Network and OU=Class 3 Public Primary Certification Authority,O=VeriSign, Inc.,C=US, respectively. You will be able to spot them in the Accepted Certificate Authority list, yet PI insists on sending empty certificate.
    Below is trace gathered from J2EE default trace. Please help shed some light
Date : 11/16/2011
Time : 8:49:11:423
Message : additional info ssl_debug(9): Starting handshake (iSaSiLk 4.3)...
ssl_debug(9): Sending v3 client_hello message to preprod.connect.elemica.com:443, requesting version 3.2...
ssl_debug(9): Received v3 server_hello handshake message.
ssl_debug(9): Server selected SSL version 3.1.
ssl_debug(9): Server created new session 22:E7:C0:9E:C1:D2:78:83...
ssl_debug(9): CipherSuite selected by server: TLS_RSA_WITH_AES_256_CBC_SHA
ssl_debug(9): CompressionMethod selected by server: NULL
ssl_debug(9): Received certificate handshake message with server certificate.
ssl_debug(9): Server sent a 1024 bit RSA certificate, chain has 2 elements.
ssl_debug(9): ChainVerifier: No trusted certificate found, OK anyway.
ssl_debug(9): Received certificate_request handshake message.
ssl_debug(9): Accepted certificate types: RSA, DSA
ssl_debug(9): Accepted certificate authorities:
ssl_debug(9):   CN=QuoVadis Global SSL ICA,OU=www.quovadisglobal.com,O=QuoVadis Limited,C=BM
ssl_debug(9):   CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB
ssl_debug(9):   CN=CSF - Classe III - Sign et Crypt,OU=Certification Professionnelle,O=Autorite Consulaire
ssl_debug(9):   CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions, Inc.,O=GTE Corporation,C=US
ssl_debug(9):   CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net
ssl_debug(9):   CN=DPWN SSL CA I2 PS,OU=I2 PS,O=Deutsche Post World Net
ssl_debug(9):   CN=CSF,O=Autorite Consulaire
ssl_debug(9):   C=BE,O=GlobalSign nv-sa,OU=RootSign Partners CA,CN=GlobalSign RootSign Partners CA
ssl_debug(9):   CN=Dell Inc. Enterprise Utility CA1,O=Dell Inc.
ssl_debug(9):   EMAIL=premium-server(a)thawte.com,CN=Thawte Premium Server CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA
ssl_debug(9):   CN=TC TrustCenter Class 2 L1 CA XI,OU=TC TrustCenter Class 2 L1 CA,O=TC TrustCenter GmbH,C=DE
ssl_debug(9):   CN=VeriSign Class 3 Extended Validation SSL SGC CA,OU=Terms of use at https://www.verisign.com/rpa (c)06,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   OU=VeriSign Trust Network,OU=(c) 1998 VeriSign, Inc. - For authorized use only,OU=Class 3 Public Primary Certification Authority - G2,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=TC TrustCenter SSL CA I,OU=TC TrustCenter SSL CA,O=TC TrustCenter GmbH,C=DE
ssl_debug(9):   CN=Entrust Root Certification Authority,OU=(c) 2006 Entrust, Inc.,OU=www.entrust.net/CPS is incorporated by reference,O=Entrust, Inc.,C=US
ssl_debug(9):   CN=VeriSign Class 3 International Server CA - G3,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=Meijer ipprod,OU=IT,OU=Merch,O=Meijer Stores Limited,L=Walker,ST=MI,C=US
ssl_debug(9):   CN=COMODO Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
ssl_debug(9):   OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,OU=VeriSign International Server CA - Class 3,OU=VeriSign, Inc.,O=VeriSign Trust Network
ssl_debug(9):   CN=UTN - DATACorp SGC,OU=http://www.usertrust.com,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US
ssl_debug(9):   CN=Deutsche Telekom CA 5,OU=Trust Center Deutsche Telekom,O=T-Systems Enterprise Services GmbH,C=DE
ssl_debug(9):   CN=TC TrustCenter Class 2 CA II,OU=TC TrustCenter Class 2 CA,O=TC TrustCenter GmbH,C=DE
ssl_debug(9):   CN=VeriSign Class 3 Secure Server CA - G2,OU=Terms of use at https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,OU=VeriSign International Server CA - Class 3,OU=VeriSign, Inc.,O=VeriSign Trust Network
ssl_debug(9):   CN=Thawte SGC CA,O=Thawte Consulting (Pty) Ltd.,C=ZA
ssl_debug(9):   CN=Bertschi CA,O=Bertschi AG (Schweiz),L=Duerrenaesch,ST=Switzerland,C=CH
ssl_debug(9):   CN=Cybertrust SureServer CA,O=GlobalSign Inc
ssl_debug(9):   CN=VeriSign Class 3 Secure Server CA,OU=Terms of use at https://www.verisign.com/rpa (c)05,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   EMAIL=server-certs(a)thawte.com,CN=Thawte Server CA,OU=Certification Services Division,O=Thawte Consulting cc,L=Cape Town,ST=Western Cape,C=ZA
ssl_debug(9):   CN=Mark Van Hamme,O=Brain2 BVBA,L=Brussels,ST=Brabant,C=BE
ssl_debug(9):   CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
ssl_debug(9):   EMAIL=bis.at(a)siemens.com,CN=bis.siemens.at,OU=SBS ORS EDO,O=Siemens Business Services,L=Vienna,ST=Vienna,C=AT
ssl_debug(9):   CN=VeriSign Class 1 Public Primary Certification Authority - G3,OU=(c) 1999 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=mail2.adr-logistics.hu,O=ADR Logistics Kft.,L=Gyu00E1l,ST=Pest,C=HU
ssl_debug(9):   EMAIL=brent.kemp(a)sscoop.com,CN=bacchusdevp.sscoop.com,OU=IS,O=Southern States Cooperative Inc,L=Richmond,ST=VA,C=US
ssl_debug(9):   CN=Cybertrust SureServer Standard Validation CA,O=Cybertrust Inc
ssl_debug(9):   OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group, Inc.,C=US
ssl_debug(9):   CN=Certipost E-Trust Secondary Normalised CA for Legal Persons,O=Certipost s.a./n.v.,C=BE
ssl_debug(9):   EMAIL=cert(a)bit-serv.de,CN=BIT-SERV GmbH Root CA,O=BIT-SERV GmbH,C=DE
ssl_debug(9):   CN=SAP_elemica_tester
ssl_debug(9):   CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US
ssl_debug(9):   OU=Class 1 Public Primary Certification Authority,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE
ssl_debug(9):   CN=Montova Root CA,OU=Root CA,O=Montova,C=BE
ssl_debug(9):   CN=Baltimore CyberTrust Root,OU=CyberTrust,O=Baltimore,C=IE
ssl_debug(9):   CN=Dell Inc. Enterprise CA,O=Dell Inc.
ssl_debug(9):   CN=COMODO High-Assurance Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
ssl_debug(9):   EMAIL=support(a)tamgroup.com,OU=Engineering,O=Tamgroup,ST=California,L=San Anselmo,C=US,CN=Tamgroup
ssl_debug(9):   CN=GlobalSign Organization Validation CA,O=GlobalSign,OU=Organization Validation CA
ssl_debug(9):   CN=Certinomis AC 1 u00E9toile,OU=0002 433998903,O=Certinomis,C=FR
ssl_debug(9):   CN=GlobalSign ServerSign CA,OU=ServerSign CA,O=GlobalSign nv-sa,C=BE
ssl_debug(9):   CN=QuoVadis Root CA 2,O=QuoVadis Limited,C=BM
ssl_debug(9):   CN=AddTrust Class 1 CA Root,OU=AddTrust TTP Network,O=AddTrust AB,C=SE
ssl_debug(9):   CN=Equifax Secure Global eBusiness CA-1,O=Equifax Secure Inc.,C=US
ssl_debug(9):   CN=GlobalSign Organization Validation CA,O=GlobalSign,OU=Organization Validation CA
ssl_debug(9):   CN=thawte Primary Root CA,OU=(c) 2006 thawte, Inc. - For authorized use only,OU=Certification Services Division,O=thawte, Inc.,C=US
ssl_debug(9):   CN=Certipost E-Trust Primary Normalised CA,O=Certipost s.a./n.v.,C=BE
ssl_debug(9):   CN=Thawte DV SSL CA,OU=Domain Validated SSL,O=Thawte, Inc.,C=US
ssl_debug(9):   OU=Equifax Secure Certificate Authority,O=Equifax,C=US
ssl_debug(9):   CN=preprod.connect.elemica.com,OU=CONNECTED SOLUTIONS,O=Elemica,L=Wayne,ST=Pennsylvania,C=US
ssl_debug(9):   CN=Certinomis - Autoritu00E9 Racine,OU=0002 433998903,O=Certinomis,C=FR
ssl_debug(9):   CN=DPWN Root CA R2 PS,OU=IT Services,O=Deutsche Post World Net,DC=com
ssl_debug(9):   CN=Thawte Test CA Root,OU=TEST TEST TEST,O=Thawte Certification,ST=FOR TESTING PURPOSES ONLY,C=ZA
ssl_debug(9):   OU=Class 3 Public Primary Certification Authority,O=VeriSign, Inc.,C=US
ssl_debug(9):   EMAIL=santiago.tolosa(a)eu.rhodia.com,CN=Rhodia Development CA,OU=ISF - WARTE,O=Rhodia,L=La Villette,ST=France,C=FR
ssl_debug(9):   CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US
ssl_debug(9):   CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US
ssl_debug(9):   CN=Groep H. Essers TEST (99805D6DA33FCC1700010002),O=Montova,C=BE
ssl_debug(9):   serialNumber=07969287,CN=Go Daddy Secure Certification Authority,OU=http://certificates.godaddy.com/repository,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US
ssl_debug(9):   CN=VeriSign Class 3 Secure Server 1024-bit CA - G2,OU=Terms of use at https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   serialNumber=10688435,CN=Starfield Secure Certification Authority,OU=http://certificates.starfieldtech.com/repository,O=Starfield Technologies, Inc.,L=Scottsdale,ST=Arizona,C=US
ssl_debug(9):   CN=Conextrade,OU=Swisscom IT,O=Swisscom AG,L=Zurich,ST=Zurich,C=CH,EMAIL=ccc.eTrade(a)swisscom.com
ssl_debug(9):   CN=b2bproto.basf-corp.com,OU=Corporate IS,O=BASF Corporation,L=Mount Olive,ST=New Jersey,C=US
ssl_debug(9):   CN=GlobalSign Domain Validation CA - G2,O=GlobalSign nv-sa,C=BE
ssl_debug(9):   CN=Swisscom Root CA 1,OU=Digital Certificate Services,O=Swisscom,C=ch
ssl_debug(9):   CN=GeoTrust DV SSL CA,OU=Domain Validated SSL,O=GeoTrust Inc.,C=US
ssl_debug(9):   EMAIL=!sysadmin(a)elemica.com,CN=www.elemica.com,OU=Connected Solutions,O=Elemica, Inc,L=Wayne,ST=Pennsylvania,C=US
ssl_debug(9):   CN=GeoTrust SSL CA,O=GeoTrust, Inc.,C=US
ssl_debug(9):   CN=RapidSSL CA,O=GeoTrust, Inc.,C=US
ssl_debug(9):   CN=Entrust Certification Authority - L1E,OU=(c) 2009 Entrust, Inc.,OU=www.entrust.net/rpa is incorporated by reference,O=Entrust, Inc.,C=US
ssl_debug(9):   CN=EAS,O=COMPUDATA EDI Dienstleister,C=CH,EMAIL=helpdesk.dl(a)compudata.ch
ssl_debug(9):   CN=GlobalSign Domain Validation CA,O=GlobalSign nv-sa,OU=Domain Validation CA,C=BE
ssl_debug(9):   CN=GlobalSign Primary Secure Server CA,OU=Primary Secure Server CA,O=GlobalSign nv-sa,C=BE
ssl_debug(9):   CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
ssl_debug(9):   CN=Entrust Root Certification Authority,OU=(c) 2006 Entrust, Inc.,OU=www.entrust.net/CPS is incorporated by reference,O=Entrust, Inc.,C=US
ssl_debug(9):   CN=Thawte SSL CA,O=Thawte, Inc.,C=US
ssl_debug(9):   CN=Entrust Certification Authority - L1C,OU=(c) 2009 Entrust, Inc.,OU=www.entrust.net/rpa is incorporated by reference,O=Entrust, Inc.,C=US
ssl_debug(9):   CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US
ssl_debug(9):   EMAIL=vladimir.polak(a)esa.ch,CN=Vladimir Polak,O=Einkaufsorganisation des Schweizerischen Auto- und Motorfahrzeuggewerbes,C=CH
ssl_debug(9):   CN=IT Directions and Strategies,OU=ITDS EDI,ST=WI,C=US,L=Hartland,EMAIL=aklumpp(a)itdsllc.com,O=ITDS EDI
ssl_debug(9):   CN=Entrust Certification Authority - L1B,OU=(c) 2008 Entrust, Inc.,OU=www.entrust.net/CPS is incorporated by reference,OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE,O=Entrust, Inc.,C=US
ssl_debug(9):   CN=GlobalSign Organization Validation CA - G2,O=GlobalSign nv-sa,C=BE
ssl_debug(9):   CN=VeriSign Class 1 Individual Subscriber CA - G3,OU=Persona Not Validated,OU=Terms of use at https://www.verisign.com/rpa (c)09,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=VeriSign Class 1 Individual Subscriber CA - G2,OU=Persona Not Validated,OU=Terms of use at https://www.verisign.com/rpa (c)05,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=TeleSec ServerPass CA 1,OU=Trust Center Services,O=T-Systems International GmbH,C=DE
ssl_debug(9):   CN=TC TrustCenter Class 3 L1 CA V,OU=TC TrustCenter Class 3 L1 CA,O=TC TrustCenter GmbH,C=DE
ssl_debug(9):   C=NL,ST=Zuid-Holland,L=Spijkenisse,O=De Rijke Transport,OU=ICT,CN=smtphost.derijke.com
ssl_debug(9):   CN=VeriSign Class 3 Secure Server CA - G3,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9):   CN=Comodo Class 3 Security Services CA,OU=(c)2002 Comodo Limited,OU=Terms and Conditions of use: http://www.comodo.net/repository,OU=Comodo Trust Network,O=Comodo Limited,C=GB
ssl_debug(9):   CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US
ssl_debug(9):   OU=Starfield Class 2 Certification Authority,O=Starfield Technologies, Inc.,C=US
ssl_debug(9):   EMAIL=ftp(a)csx.com,C=US,O=CSX Corporation Inc,CN=CSX_CORPORATION_AS2_02062009
ssl_debug(9):   CN=EssentialSSL CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
ssl_debug(9):   CN=Network Solutions Certificate Authority,O=Network Solutions L.L.C.,C=US
ssl_debug(9):   CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) 2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US
ssl_debug(9): Received server_hello_done handshake message.
ssl_debug(9): No client certificate available, sending empty certificate message...
ssl_debug(9): Sending client_key_exchange handshake...
ssl_debug(9): Sending change_cipher_spec message...
ssl_debug(9): Sending finished message...
ssl_debug(9): Received alert message: Alert Fatal: bad certificate
ssl_debug(9): SSLException while handshaking: Peer sent alert: Alert Fatal: bad certificate
ssl_debug(9): Shutting down SSL layer...
Severity : Error
Category : /Applications/ExchangeInfrastructure/AdapterFramework/SAPLibraries/SAPXDK
Location : com.sap.aii.messaging.net.HTTPClientConnection.call(Object)
Application : sap.com/com.sap.xi.rwb
Thread : SAPEngine_Application_Thread[impl:3]_0
Datasource : 7662250:E:\usr\sap\T37\DVEBMGS00\j2ee\cluster\server0\log\defaultTrace.trc
Message ID : 00505688007A006A0000005100001B8C0004B1CF78E9602A
Source Name : com.sap.aii.messaging.net.HTTPClientConnection
Argument Objs :
Arguments :
Dsr Component :
Dsr Transaction : cc6d1cee0fec11e1c90200000074eaaa
Dsr User :
Indent : 0
Level : 0
Message Code :
Message Type : 0
Relatives : /Applications/ExchangeInfrastructure/AdapterFramework/SAPLibraries/SAPXDK
Resource Bundlename :
Session : 365
Source : com.sap.aii.messaging.net.HTTPClientConnection
ThreadObject : SAPEngine_Application_Thread[impl:3]_0
Transaction :
User : CPWONG
Dsr Root Context ID :
Dsr Connection :
Dsr Counter : -1

Hi ,
Is the above problem solved , can you share the solution.
Thanks

Non-Deterministic Exception When Connecting With Wrong Client Certificate

I am working on an internal application and need to determine the correct client-side SSL certificate to use when connecting to a server (the user can supply multiple client-side certificates). I had expected that if I connected to a server using the wrong client certificate the java client would throw a SSLHandshakeException and I could then try the next certificate. This seems to work some of the time, however the java client will sometimes throw a SocketException: Software caused connection abort: recv failed, in which case it is not possible to know that the wrong certificate caused the problem.
Below is the code I have been using to test as well as the intermittent SocketException stack trace. Does anyone have an idea as to how to fix this problem? Thanks in advance.
Note: the TrustAllX509TrustManager is a trust manager that trusts all servers.
protected void connectSsl() throws Exception {
      final String host = "x.x.x.x";
      final int portNumber = 443;
      final int socketTimeout = 10*1000;
      // Note: Wrong certificate (expect SSLHandshakeException).
      final String certFilename = "C:\\xxx\\clientSSL.P12";
      final String certPassword = "certPassword";
      final BufferedInputStream bis = new BufferedInputStream(new FileInputStream(new File(certFilename)));
      final char[] certificatePasswordArray = certPassword.toCharArray();
      final KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance("SunX509");
      final KeyStore keyStore = KeyStore.getInstance("PKCS12");
      keyStore.load(bis, certificatePasswordArray);
      keyManagerFactory.init(keyStore, certificatePasswordArray);
      final KeyManager[] keyManagers = keyManagerFactory.getKeyManagers();
      final SSLContext context = SSLContext.getInstance("SSL");
      context.init(keyManagers, new TrustManager[]{new TrustAllX509TrustManager()}, new SecureRandom());
      final SocketFactory secureFactory = context.getSocketFactory();
      final Socket socket = secureFactory.createSocket();
      final InetAddress ip = InetAddress.getByName(host);
      socket.connect(new InetSocketAddress(ip, portNumber), socketTimeout);
      socket.setSoTimeout(socketTimeout);
      // Write the request.
      final OutputStream out = new BufferedOutputStream(socket.getOutputStream());
      out.write("GET / HTTP/1.1\r\n".getBytes());
      out.write("\r\n".getBytes());
      out.flush();
      InputStream inputStream = socket.getInputStream();
      ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
      byte[] byteArray = new byte[1024];
      int bytesRead = 0;
      while ((bytesRead = inputStream.read(byteArray)) != -1) {
         outputStream.write(byteArray, 0, bytesRead);
      socket.close();
      System.out.println("Response:\r\n" + outputStream.toString("UTF-8"));
   }Unexpected SocketException:
main: java.net.SocketException: Software caused connection abort: recv failed
     at java.net.SocketInputStream.socketRead0(Native Method)
     at java.net.SocketInputStream.read(SocketInputStream.java:129)
     at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
     at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1435)
     at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(HandshakeOutStream.java:103)
     at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:612)
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:808)
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:734)
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:197)
     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.writeRecord(SSLSocketImpl.java:623)
     at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:59)
     at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
     at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)

Thanks for the quick response. Here are answers to the questions:
1) No, this issue is not associated with one particular certificate. I have tried several certificates and see the same issue.
2) I agree it would be simpler to only send the required certificate, but unfortunately the project requires that the user be able to specify multiple certificates and, if a client-side certificate is required, the application try each one in turn until the correct certificate is found.
3) Yes, I realize the TrustAllX509TrustManager is insecure, but I am using this for testing purposes while trying to diagnose the client certificate problem.
In terms of testing, I am just wrapping the above code in a try/catch block and executing it in a loop. It is quite odd that the same exact code will sometimes generate a SSLHandshakeException and other times a SocketException.
One additional piece of information: if I force the client code to use "SSLv3" using the Socket.setEnabledProtocols(...) method, the problem goes away (I consistently get a SSLHandshakeException). However, I don't think this solves my problem as forcing the application to use SSLv3 would mean it could not handle TLS connections.
The code to specify the SSLv3 protocol is:
SSLSocket sslSocket = (SSLSocket) socket;
sslSocket.setEnabledProtocols(new String[] {"SSLv3"});
One other strange issue: if instead of specifying the SSLv3 protocol using setEnabledProtocols(...) I instead specify the protocol when creating the SSLContext, the SocketException problem comes back. So if I replace:
final SSLContext context = SSLContext.getInstance("SSL");
with:
final SSLContext context = SSLContext.getInstance("SSLv3");
and remove the "sslSocket.setEnabledProtocols(new String[] {"SSLv3"})" line, I see the intermittent SocketException problem.
All very weird. Any thoughts?

Safari client certificate problem w/ Canada Post website

I am using OSX 10.8.5 and Safari 6.1.1
I'm trying to use the Canada Post website for online shipping (ship-in-a-click) via the site:
http://www.canadapost.ca/personal/tools/cst/intro-e.asp
When I choose my option (in this case INTERNATIONAL) a pop-up opens asking to select a client certificate. A list of five certificates, which are all apparently valid and not expired, is given. No matter which certificate I select I cannot get past this pop up window. It just pops back up again.
The certificates are all in the form:
com.apple.idms.appleid.prd. then a very lengthy alpha numeric string
From what I have read with certificate problems you can just delete them and next time you visit the site will ask you to select a new one. However, in this case, with all the certificates seemingly being valid, I don't think that will be the solution. Although, I am a complete novice when it comes to these issues.
Can anybody suggest something other than using Firefox/Chrome etc. although if that is the ONLY choice then so be it. But surely this can be solved within Safari, no? The rest of the Canada Post site seems to behave OK with Safari.
Thank you.

Neither. I am on Mavericks and it shows the exact same issue, so it neither fixes the problem or intoduces new ones, at least with my site.
I also noticed that it is somewhat based on the loction (IP) of the server because on my local laptop (During development) and on our QA server would try and send a certificate that it should not send. HOWEVER once we implemented the SSL client certificate on our production server it would no longer send the certificate. I have no idea why and speculate that it is because our production server has a public IP.
If you want you can use my site and see if the problem persists for you there (http://whf.to); however given the seemingly random why Safari decides to send certificates you may or may not see the issue. If Safari does indeed send a certificate you should get an error page that details what happened (in somewhat lay-terms).
Sorry that Mavericks doesn't fix the issue for you.

IOS4, apple-mobile-web-app-capable and client certificates

IOS4 (4.0 and 4.0.1) seems to have broken apple-mobile-web-app-capable. I have a webbapplication using client certificates to authenticate the user. This worked flawless on IOS3.x. However, after having upgraded my iPhone to IOS4, the application fails when started from the springboard with an error message telling a client certificate is required (I have one installed). When I start the application from within Safari it works OK. I tracked the error down to the following line in the HTML code:
<meta name="apple-mobile-web-app-capable" content="yes" />
When I remove this line, the application works again flawless when started from the springboard. However the native look and feel are gone. As soon as I add this line to the HTML, the application works when started from Safari, but fails when started from the springboard.
Does anyone have a glue or is this a bug on the apple-mobile-web-app-capable function of IOS4?

I have also experienced this problem on iOS 4.1. I want to authenticate access to a web-app using SSL client certificates but I get an error "Cannot Open ... requires a client certificate" when launching the app from the home screen. Very annoying!
Navigating to the page in Safafi prompts the user to choose which certificate to use and then loads the page successfully. Just as a side question, is there anyway to automatically associate a client certificate with a web site so that the user is never prompted to choose a certificate when accessing the site? I want an authentication process that is transparent to the user.

Android Setting up mail requires a client certificate

I have just got a new Asus ZenFone 2 and trying to add an Exchange account to the built-in Email app. My Exchange Server is Office 365.
After entering Email address, Password and Server (https://outlook.office365.com/mapi/emsmdb/?Mailbox=....a-long-guid....), it insists on a Client certificate. Where do
I get this Client certificate? When I touch Select, it says:
Choose certificate
The app Email has requested a certificate. Choosing a certificate will let the app use this identity with servers now and in the future.
You can install certificates from a PKCS#12 file with a .pfx or a .p12 extension located in external storage.
What is going on here?
Thanks.

I solved it by ignoring it.
Previously, I couldn't proceed as the Next button was disabled. I found that it was disabled because the server name is given in the wrong format. I got the
https://outlook.office365.com/mapi/emsmdb/?..... version from the configuration dialog in my desktop Outlook set up.
The proper way to enter the Exchange server for Office 365 is simply outlook.office365.com!

Asking specific client certificate (not certificates trusted by authority)

As I understand from what I read so far, during the handshake negotiation for two way ssl, the server sends the client a list of trusted certificate authorities and say to the client: "hey, those are the authorities I trust. send me a certificate that can be verified by one of them".
I also read how you can customize SSLSocketFactory to, on the client side, look for a specific certificate alias (http://www.ibm.com/developerworks/java/library/j-customssl/). I would like to move this idea further and ask for specific certificates depending on what resources the user is trying to access.
For example:
Let's suppose I have two resources on my server called "bobPrivateStuff" and "alicePrivateStuff". I also have a certificate authority who can validate both Bob and Alice certificates on a custom trust keystore. In a regular scenario, the server will ask for a client certificate and will accept either Alice or Bob certificate, as both can be verified by the custom trust.
But what if Alice can't access "bobPrivateStuff"? What if when trying to open a connection, to say http://myserver.com/services/bobPrivateStuff, the server asks specifically for Bob's certificate? Can I setup the handshake in a way it will actually ask for Bob's certificate instead of only just "any certificated trusted by this CA"?
And what piece of information could be used to distinguish one certificate from another? Is the serial number unique between multiple certificates? Is this pushing the envelop too much and trying to use SSL for more than what it is intended for?

I agree 100%. It's just that we want to use certificates to validate the client's identity (instead of relying on username/password).Fine, that's exactly what SSL & PKI will do for you.
It might not be elegantBut it is!
See my point?Of course I see your point. SSL already does that. I said that. You agreed. I agree. What it doesn't do is the authorization part. Because it can't. It isn't meant to. You are supposed to do that.
Instead of the server asking for a specific certificate, it justs checks if the certificate sent by the client has access to the resource.Not quite. It should check if the identity represented by the client certificate (Certificate.getSubjectX500Principal(), or SSLSocket.getSession().getPeerPrincipal()) has access to the resource.
This way, we can leave the server untouchedNo you can't. The server has to get hold of the client principal after the handshake and authorize it against the resource.
if Bob wants to access some resources, Bob has to prove he is who he says he is.You're still confused. That's authentication, and SSL already does that for you. SSLSocket.getSession().getPeerPrincipal() returns you the authenticated identity of the peer. The server then has to check that that identity can access that resource. This is 'authorization'. You can't automate it via keystores and truststores. That's not what they do and it's not what they're for.
So I think it is perfectly plausible to do this kind of verification on the server side (i.e. "hijack" a certificate sent to validate the ssl handshake to also verify if the user has the correct privileges).There's no 'hijacking' about it, but you're concentrating on the certificate instead of the identity it represents. A client could have a large number of certificates that all authenticate the same identity. You need to think in terms of authorizing Principals to access resources.

Project Server 2010 Web services access with Client Certificate Authentication

We switched our SharePoint/Project Server 2010 farm to use client certificate authentication with Active Directory Federation Services (AD FS) 2.0, which is working without issue. We have some administrative Project Server Interface (PSI)
web service applications that no longer connect to server with the new authentication configuration. Our custom applications are using the WCF interface to access the public web services.
Please let us know if it is possible to authenticate with AD FS 2.0 and then call
Project Server web services. Any help or coding examples would be greatly appreciated.

what is the error occurred when the custom PSI app connects?
can you upload the ULS logs here for research?
What is the user account format you specified in the code for authentication?
For proper authorization, the “user logon account” in PWA for the user needs to be changed from domain\username to the claims token (e.g.
'I:0#.w|mybusinessdomain\ewmccarty').
It requires you to manually call the UpnLogon method of
“Claims to Windows Token Service”. if (Thread.CurrentPrincipal.Identity is ClaimsIdentity)
{ var identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity; }
if (Thread.CurrentPrincipal.Identity is ClaimsIdentity)
var identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity;
Than you need to extract UPN-Claim from the identity.
Upload the verbose log if possible.
Did you see this?
http://msdn.microsoft.com/en-us/library/ff181538(v=office.14).aspx
Cheers. Happy troubleshooting !!! Sriram E - MSFT Enterprise Project Management

Help required with ADFS 3.0 client certificate authentication

Hi,
I am currently working on integrating ADFS 3.o for Single Sign On to some 3rd party services along with PKI solution. The basic requirement is that I should be able to choose client authentication certificate as an authentication method in ADFS and then
federate user credentials to 3rd party trust for single-sign-on.
I had done this successfully with ADFS 2.0 and that setup is working fine. I have the setup as ADFS 3.0 client authentication method enabled. When I open browser to logon, the ADFS 3.0 page displays a message as "Select a certificate that you want to
use for authentication. If you cancel the operation, please close your browser and try again." but the certificates are not displayed for selection.
The certificates are valid and have valid chaining to CA. Could someone help me resolve this issue?
Thanks!
-Chinmaya Karve

Hi Yan,
Thanks for your response. I have gone through the posts that you have suggested, and my setup looks pretty much as expected.
So, as I mentioned earlier, I have 2 parallel setups with 3rd party service(SalesForce). Once of them is running ADFS 2.0 and another one has ADFS 3.0. I can logon to the third-party services, from both the setups using username/format. I can logon to SF
using client authentication certificate from ADFS 2.0 setup, but from the same client machine, when I try to logon SF via ADFS 3.0, the browser just does not pick up any certificate. The page just shows message of "Select a certificate that you want to use
for authentication. If you cancel the operation, please close your browser and try again.".
I have checked the browser, and it has the right certificates. Also, the same browser/machine is used to logon to SF through ADFS 2.0 via client certificate, which works just fine !
I am really confused now, as to whose issue this really is...
Just to confirm, I am using Certificate Authentication from ADFS 3.0 Authentication Methods for both Intranet and Extranet.
Any suggestion or inputs where I could have gone wrong in the setup?
Thanks!

IPhone Mail app; IMAP; x509 client certificate?

The title says it all really.
I have an x509 client certificate happily installed in my iPhone's keychain. This certificate works correctly in Safari, allowing access to sites which demand it. When I try to collect mail from an IMAP server which also requires a client certificate, it doesn't work.
As far as I can work out, the Mail app is not sending my client certificate when the server requests it to do so. Is this true? Is there a way to configure the Mail app to respond correctly to the server's client certificate request? Any pointers or information welcome!

I think so.
Actually I think I need to get the App Password for Mail on my phone. It generates the app password and I enter it into the password in the gmail setup for mail.
The problem is that when I hit next on that page, I get the message:
"my name" is already added" and I cannot proceed.
Before doing this setup I deleted my gmail account by tapping the email address and hitting delete in the Mail, Contact and Calendars setup..
but, there is something hiding in my iPhone that remembers my old gmail password (I guess) and doesn't let me proceed.
If I enter my gmail iChain password I get the same thing.
If i do this in airplane mode (no connection to google) i also get the same.
I talked to an apple care person who had me reset all my settings... still the same thing.
I am trying to avoid a gull reset of the iPhone, but that may be in the cards.
Going to go to the apple store and ask there, but i am not hopeful.
Barry

Problem in reading client certificate

Hi,
I am developing an web app. where client will use smart card for authentication.
And server will read the clients certificate. All the application will run in https.
So please guide me to develop such a system. I am using tomcat 6x and have created a server certificate by keytool.
I am not using openssl.
Please help me....
Thanx in advance.

hi
when you pass the manual entry posting date will be 31.03.2009 and period will be 13 because when we close the year still open 4 special period to post further entries.
Regards
Tanmoy

How can I prevent client certificate information from being written to kjs log?

I have an application running on iPlanet Application server 6.0 that makes an SSL connection to an external site using client certificate. Problem : Every time the connection is wrapped in a client certificate, the entire SSL handshake including the key-exchange information is automatically being logged in the kjs log. How do I prevent the kjs from writing this inormation to the log ?

How are you making this SSL connection? Whatever library you are using must be writing to System.out().
You could avoid logging these messages by using file logs rather than console logs. But you could probably disable these messages by working with your SSL libraries as well.

Client certificate authentication with custom authorization for J2EE roles?

We have a Java application deployed on Sun Java Web Server 7.0u2 where we would like to secure it with client certificates, and a custom mapping of subject DNs onto J2EE roles (e.g., "visitor", "registered-user", "admin"). If we our web.xml includes:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>certificate</realm-name>
<login-config>that will enforce that only users with valid client certs can access our app, but I don't see any hook for mapping different roles. Is there one? Can anyone point to documentation, or an example?
On the other hand, if we wanted to create a custom realm, the only documentation I have found is the sample JDBCRealm, which includes extending IASPasswordLoginModule. In our case, we wouldn't want to prompt for a password, we would want to examine the client certificate, so we would want to extend some base class higher up the hierarchy. I'm not sure whether I can provide any class that implements javax.security.auth.spi.LoginModule, or whether the WebServer requires it to implement or extend something more specific. It would be ideal if there were an IASCertificateLoginModule that handled the certificate authentication, and allowed me to access the subject DN info from the certificate (e.g., thru a javax.security.auth.Subject) and cache group info to support a specialized IASRealm::getGroupNames(string user) method for authorization. In a case like that, I'm not sure whether the web.xml should be:
<login-config>
 <auth-method>CLIENT-CERT</auth-method>
 <realm-name>MyRealm</realm-name>
<login-config>or:
<login-config>
 <auth-method>MyRealm</auth-method>
<login-config>Anybody done anything like this before?
--Thanks

We have JDBCRealm.java and JDBCLoginModule.java in <ws-install-dir>/samples/java/webapps/security/jdbcrealm/src/samples/security/jdbcrealm. I think we need to tweak it to suite our needs :
$cat JDBCRealm.java
* JDBCRealm for supporting RDBMS authentication.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to
* implement both a login module (see JDBCLoginModule for an example)
* which performs the authentication and a realm (as shown by this
* class) which is used to manage other realm operations.
* A custom realm should implement the following methods:
* <ul>
* <li>init(props)
* <li>getAuthType()
* <li>getGroupNames(username)
* </ul>
* IASRealm and other classes and fields referenced in the sample
* code should be treated as opaque undocumented interfaces.
final public class JDBCRealm extends IASRealm
 protected void init(Properties props)
 throws BadRealmException, NoSuchRealmException
 public java.util.Enumeration getGroupNames (String username)
 throws InvalidOperationException, NoSuchUserException
 public void setGroupNames(String username, String[] groups)
}and
$cat JDBCLoginModule.java
* JDBCRealm login module.
* This login module provides a sample implementation of a custom realm.
* You may use this sample as a template for creating alternate custom
* authentication realm implementations to suit your applications needs.
* In order to plug in a realm into the server you need to implement
* both a login module (as shown by this class) which performs the
* authentication and a realm (see JDBCRealm for an example) which is used
* to manage other realm operations.
* The PasswordLoginModule class is a JAAS LoginModule and must be
* extended by this class. PasswordLoginModule provides internal
* implementations for all the LoginModule methods (such as login(),
* commit()). This class should not override these methods.
* This class is only required to implement the authenticate() method as
* shown below. The following rules need to be followed in the implementation
* of this method:
* <ul>
* <li>Your code should obtain the user and password to authenticate from
* _username and _password fields, respectively.
* <li>The authenticate method must finish with this call:
* return commitAuthentication(_username, _password, _currentRealm,
* grpList);
* <li>The grpList parameter is a String[] which can optionally be
* populated to contain the list of groups this user belongs to
* </ul>
* The PasswordLoginModule, AuthenticationStatus and other classes and
* fields referenced in the sample code should be treated as opaque
* undocumented interfaces.
* Sample setting in server.xml for JDBCLoginModule
* <pre>
* <auth-realm name="jdbc" classname="samples.security.jdbcrealm.JDBCRealm">
* <property name="dbdrivername" value="com.pointbase.jdbc.jdbcUniversalDriver"/>
* <property name="jaas-context" value="jdbcRealm"/>
* </auth-realm>
* </pre>
public class JDBCLoginModule extends PasswordLoginModule
 protected AuthenticationStatus authenticate()
 throws LoginException
 private String[] authenticate(String username,String passwd)
 private Connection getConnection() throws SQLException
}One more article [http://developers.sun.com/appserver/reference/techart/as8_authentication/]
You can try to extend "com/iplanet/ias/security/auth/realm/certificate/CertificateRealm.java"
[http://fisheye5.cenqua.com/browse/glassfish/appserv-core/src/java/com/sun/enterprise/security/auth/realm/certificate/CertificateRealm.java?r=SJSAS_9_0]
$cat CertificateRealm.java
package com.iplanet.ias.security.auth.realm.certificate;
* Realm wrapper for supporting certificate authentication.
* The certificate realm provides the security-service functionality
* needed to process a client-cert authentication. Since the SSL processing,
* and client certificate verification is done by NSS, no authentication
* is actually done by this realm. It only serves the purpose of being
* registered as the certificate handler realm and to service group
* membership requests during web container role checks.
* There is no JAAS LoginModule corresponding to the certificate
* realm. The purpose of a JAAS LoginModule is to implement the actual
* authentication processing, which for the case of this certificate
* realm is already done by the time execution gets to Java.
* The certificate realm needs the following properties in its
* configuration: None.
* The following optional attributes can also be specified:
* <ul>
* <li>assign-groups - A comma-separated list of group names which
* will be assigned to all users who present a cryptographically
* valid certificate. Since groups are otherwise not supported
* by the cert realm, this allows grouping cert users
* for convenience.
* </ul>
public class CertificateRealm extends IASRealm
 protected void init(Properties props)
 * Returns the name of all the groups that this user belongs to.
 * @param username Name of the user in this realm whose group listing
 * is needed.
 * @return Enumeration of group names (strings).
 * @exception InvalidOperationException thrown if the realm does not
 * support this operation - e.g. Certificate realm does not support
 * this operation.
 public Enumeration getGroupNames(String username)
 throws NoSuchUserException, InvalidOperationException
 * Complete authentication of certificate user.
 * As noted, the certificate realm does not do the actual
 * authentication (signature and cert chain validation) for
 * the user certificate, this is done earlier in NSS. This default
 * implementation does nothing. The call has been preserved from S1AS
 * as a placeholder for potential subclasses which may take some
 * action.
 * @param certs The array of certificates provided in the request.
 public void authenticate(X509Certificate certs[])
 throws LoginException
 // Set up SecurityContext, but that is not applicable to S1WS..
}Edited by: mv on Apr 24, 2009 7:04 AM

[solved] weechat client certificates broken?

Similar Messages

Maybe you are looking for