Client certificate not being presented by Sun JDK

I have a requirement to connect to an external service provider (SP) using an https get.
The SP has a server certificate that I have imported to my trust store.
The SP issued a private key and an intermediate certificate that I have included in my keystore.
On running the application with IBM JDK1.5 the server responds with the error HTTP Error 403.7 - Forbidden: SSL client certificate is required"
However on running the same test application with IBM JDK1.4.2 I get the expected response from the client.
I have attached the contents of the keystore, the contents of thejava class that I am trying to connect with and and the command line options that I am using below.
Has any one encountered anything similiar?
{code}contents of Keystore:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: testinter
Creation date: Mar 6, 2008
Entry type: trustedCertEntry
Owner: CN=test Solutions CA, OU=Class 2 OnSite Individual Subscriber C
A, OU=Terms of use at https://www.verisign.com/rpa (c)06, OU=VeriSign Trust Netw
ork, O=test Solutions, C=US
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized
use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign,
Inc.", C=US
Serial number: 98da226f38da2ce29c65e35d505ec36
Valid from: Tue Jan 24 16:00:00 PST 2006 until: Mon Jan 24 15:59:59 PST 2011
Certificate fingerprints:
MD5: D1:7D:C2:B2:30:3E:26:9B:AE:5D:4C:8C:C7:10:B0:E0
SHA1: 4C:3B:59:67:F4:DE:08:0B:8C:70:AE:0D:05:1E:D1:18:46:00:FC:2D
Alias name: testclient
Creation date: Mar 6, 2008
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: [email protected], CN=BHN AST, T=Programmer, OU="
Security Phrase - 1111+!", OU=Company - Test Networks, OU="www.verisign.c
om/repository/CPS Incorp. by Ref.,LIAB.LTD(c)99", OU=Data Center, O=test Prepa
id Solutions
Issuer: CN=test Solutions CA, OU=Class 2 OnSite Individual Subscriber
CA, OU=Terms of use at https://www.verisign.com/rpa (c)06, OU=VeriSign Trust Net
work, O=test Solutions, C=US
Serial number: 769ed3a8a02a78a45ba2ce46e974f444
Valid from: Wed Mar 05 16:00:00 PST 2008 until: Fri Mar 06 15:59:59 PST 2009
Certificate fingerprints:
MD5: 2D:6E:37:83:BD:B8:FB:32:0E:08:B7:C5:F9:52:F3:C6
SHA1: B9:61:D9:D9:F2:B5:9B:5E:9D:73:D2:FB:7A:B6:04:BE:0A:4F:E5:27
*******************************************{code}
I am providing the following JVM arguments in my command line:
{code}-Djavax.net.ssl.keyStore
-Djavax.net.ssl.keyStorePassword
-Djavax.net.ssl.trustStore
-Djavax.net.ssl.trustStorePassword{code}
I use org.apache.commons.httpclient.HttpClient. I have pasted the code below, though this might not be relevant.
{code}
public class MySimpleTest {
public static void main(String[] args) {
HttpClient client = new HttpClient();
String url = "https://sample.domain.com:443/a2a/CO_TestCall.asp?userid=me&password=hello"
String url = null;
GetMethod getMethod;
try {
// start- Proxy authentication changes
client.setTimeout(30000);
client.getParams().setParameter("http.useragent", "X-HTTP-UserAgent: Mozilla/4.0 (compatible; MMozilla/4.0SIE 6.0");
client.getParams().setSoTimeout(3000);
client.getParams().setParameter("http.socket.timeout", new Integer(30000));
client.getHttpConnectionManager().getParams().setConnectionTimeout(30000);
getMethod = new GetMethod(url);
client.executeMethod(getMethod);
String xmlString = getMethod.getResponseBodyAsString();
System.out.println("Response from SP - \n" + xmlString);
} catch (HttpException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}{code}
Edited by: dhanyakairali on Nov 26, 2008 2:24 PM

What do you mean by the following:
That's probably because it can't find a certificate that matches the cipher suites and CAs specified in the Certificate Request message
Is there some way this can be resolved?
Following is the debug output using IBM JDK1.4. The response from the server is as expected.
Dec 2, 2008 10:56:58 AM org.apache.commons.httpclient.auth.AuthChallengeProcesso
r selectAuthScheme
INFO: basic authentication scheme selected
IBMJSSEProvider Build-Level: -20050926
trustStore is: C:/test/telecom.ks
trustStore type is : jks
init truststore
This is a cert =[
Version: V3
Subject: [email protected], CN=TestAST, T=Programmer,
OU="Security Phrase - 1111+!", OU=Company - Test Networks, OU="www.verisi
gn.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)99", OU=Data Center, O=test P
repaid Solutions, ST=CA, C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: IBMJCE RSA Public Key:
modulus:
13700328555797653992422405008895136799144702421032746442303924045960508846129827
37401767169101170952814528896263872577201854818466933232859315777147275637960851
92040201921570983415043931612942054809265710771489792766258003906198481883302677
501158985042407358121382552144568843482651891301118466381829467239017
public exponent:
65537
Validity: [From: Sun Mar 11 16:00:00 PST 2007,
               To: Tue Mar 11 15:59:59 PST 2008]
Issuer: CN=test Prepaid Solutions CA, OU=Class 2 OnSite Individual Subscribe
r CA, OU=Terms of use at https://www.verisign.com/rpa (c)06, OU=VeriSign Trust N
etwork, O=test Prepaid Solutions, C=US
SerialNumber: [116300044034181362695735633430106044869]
Certificate Extensions: 5
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
   SSL client
[2]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
[3]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
PolicyInformation: [
        CertPolicyId: 2.16.840.1.113733.1.7.23.2
        PolicyQualifiers: [PolicyQualifierInfo: [
CPSuri: [
        object identifier: 1.3.6.1.5.5.7.2.1
        uri: https://www.verisign.com/rpa]
[4]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
1 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [URIName: http://onsitecrl.verisign.com/testP
repaidSolutionsDataCenter/LatestCRL.crl]
        Reason Flags: null
        Issuer: null
[5]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_Encipherment
Algorithm: [MD5withRSA]
Signature:
0000: a9 9a de a4 8a 63 6c d1 c4 a6 cd e1 28 13 90 e5 .....cl.........
0010: 0f bd ff 08 08 aa 45 05 a7 f0 a2 ea ed a7 82 77 ......E........w
0020: 9a 59 c1 5a 55 f9 d9 60 fe ff b9 bf 5e ac ae be .Y.ZU...........
0030: 6b 0f 12 b9 de 63 d2 34 90 6a 2d 43 6b 16 eb 22 k....c.4.j.Ck...
0040: f5 6e 2a c0 dc 95 75 7e 2f fe 5e a4 4d 76 0e ca .n....u.....Mv..
0050: 56 7f 20 d4 88 9b d9 00 0e b0 63 3a 62 2e da e1 V.........c.b...
0060: d8 a3 0c da 16 0e eb 3a c8 39 e4 23 b7 59 f9 03 .........9...Y..
0070: 68 e6 1c 6a 7f ce 89 ba e8 f1 02 87 7e 19 80 7e h..j............
0080: 33 8b 17 66 33 28 ce 5f f6 12 03 ba 48 60 06 4f 3..f3.......H..O
0090: b4 56 af 8d 0c 59 c3 0e ec 7f 76 37 82 03 30 70 .V...Y....v7..0p
00a0: 6d 7e de 9b 06 2b 41 13 19 e2 ca 2c 98 c6 82 7c m.....A.........
00b0: 5d dc d0 2d 23 27 24 28 08 a5 2d 24 1a 1e 20 44 ...............D
00c0: 63 cd b0 04 97 ac 71 97 04 12 f7 fe 79 40 d2 95 c.....q.....y...
00d0: 0c ea 3e 96 06 3d 28 04 a2 6d ec ef d1 61 17 19 .........m...a..
00e0: d0 bc 7d a9 a8 d7 86 28 68 cd 8c bd 88 02 48 76 ........h.....Hv
00f0: ac f8 58 9e 5a f6 12 22 7a 3d c1 77 52 e4 4a 1c ..X.Z...z..wR.J.
This is a cert =[
Version: V3
Subject: CN=Entrust.net Client Certification Authority, OU=(c) 1999 Entrust.ne
t Limited, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., O
=Entrust.net, C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: IBMJCE RSA Public Key:
modulus:
14060551710975481933679958427775412995993933516866022052634173307104123356793897
86029054872741136587347742365042373051727361425820266702866562193067033437895460
98897297163835299300640686715935681464440623967085658420014139658593602796229395
160423430303106875229776994060540049647635218875669343075088279205771
public exponent:
3
Validity: [From: Tue Oct 12 12:24:30 PDT 1999,
               To: Sat Oct 12 12:54:30 PDT 2019]
Issuer: CN=Entrust.net Client Certification Authority, OU=(c) 1999 Entrust.net
Limited, OU=www.entrust.net/Client_CA_Info/CPS incorp. by ref. limits liab., O=
Entrust.net, C=US
SerialNumber: [939758062]
Certificate Extensions: 8
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: c4 fb 9c 29 7b 97 cd 4c 96 fc ee 5b b3 ca 99 74 .......L.......t
0010: 8b 95 ea 4c                                        ...L
[2]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
   SSL CA
   S/MIME CA
   Object Signing CA]
[3]: ObjectId: 1.2.840.113533.7.65.0 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 0c 30 0a 1b 04 56 34 2e 30 03 02 04 90        ..0...V4.0....
[4]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
[5]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
2 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [CN=CRL1, CN=Entrust.net Client Certification A
uthority, OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/Client_CA_Info/CPS
incorp. by ref. limits liab., O=Entrust.net, C=US]
        Reason Flags: null
        Issuer: null
Distribution Point: [
        Distribution Point Name: [URIName: http://www.entrust.net/CRL/Client1.cr
l]
        Reason Flags: null
        Issuer: null
[6]: ObjectId: 2.5.29.16 Criticality=false
PrivateKeyUsage: [
From: Tue Oct 12 12:24:30 PDT 1999, To: Sat Oct 12 12:24:30 PDT 2019]
[7]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
Key_CertSign
Crl_Sign
[8]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: c4 fb 9c 29 7b 97 cd 4c 96 fc ee 5b b3 ca 99 74 .......L.......t
0010: 8b 95 ea 4c                                        ...L
Algorithm: [MD5withRSA]
Signature:
0000: 3f ae 8a f1 d7 66 03 05 9e 3e fa ea 1c 46 bb a4 .....f.......F..
0010: 5b 8f 78 9a 12 48 99 f9 f4 35 de 0c 36 07 02 6b ..x..H...5..6..k
0020: 10 3a 89 14 81 9c 31 a6 7c b2 41 b2 6a e7 07 01 ......1...A.j...
0030: a1 4b f9 9f 25 3b 96 ca 99 c3 3e a1 51 1c f3 c3 .K..........Q...
0040: 2e 44 f7 b0 67 46 aa 92 e5 3b da 1c 19 14 38 30 .D..gF........80
0050: d5 e2 a2 31 25 2e f1 ec 45 38 ed f8 06 58 03 73 ...1....E8...X.s
0060: 62 b0 10 31 8f 40 bf 64 e0 5c 3e c5 4f 1f da 12 b..1...d....O...
0070: 43 ff 4c e6 06 26 a8 9b 19 aa 44 3c 76 b2 5c ec C.L.......D.v...
This is a cert =[
Version: V1
Subject: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authoriz
ed use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSig
n, Inc.", C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
14351375969537625669855198831991651295191487241251642784842741254494712862136652
49865861338724286276052570119645627384360370149490030232076841237655805776438569
02490012206184342797701338702212847300700510904054461415882447323962515420981673
690656531522653631627254509600778128478935206940338665570318609767527
public exponent:
65537
Validity: [From: Sun May 17 17:00:00 PDT 1998,
               To: Tue Aug 01 16:59:59 PDT 2028]
Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorize
d use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign
, Inc.", C=US
SerialNumber: [167285380242319648451154478808036881606]
Algorithm: [SHA1withRSA]
Signature:
0000: 51 4d cd be 5c cb 98 19 9c 15 b2 01 39 78 2e 4d QM..........9x.M
0010: 0f 67 70 70 99 c6 10 5a 94 a4 53 4d 54 6d 2b af .gpp...Z..SMTm..
0020: 0d 5d 40 8b 64 d3 d7 ee de 56 61 92 5f a6 c4 1d ....d....Va.....
0030: 10 61 36 d3 2c 27 3c e8 29 09 b9 11 64 74 cc b5 .a6.........dt..
0040: 73 9f 1c 48 a9 bc 61 01 ee e2 17 a6 0c e3 40 08 s..H..a.........
0050: 3b 0e e7 eb 44 73 2a 9a f1 69 92 ef 71 14 c3 39 ....Ds...i..q..9
0060: ac 71 a7 91 09 6f e4 71 06 b3 ba 59 57 26 79 00 .q...o.q...YW.y.
0070: f6 f8 0d a2 33 30 28 d4 aa 58 a0 9d 9d 69 91 fd ....30...X...i..
This is a cert =[
Version: V3
Subject: [email protected], CN=Thawte Personal Basic CA,
OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western
Cape, C=ZA
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: IBMJCE RSA Public Key:
modulus:
13253536386354654913138758702689025560687846640885974128606081482411288972669674
09593694394214448269934071264255335350958443035659786636087648033000633904576847
89299407573545577463510566656987897345834861794576009248121771398416136278226650
196253637652406375166996828928456019641867231766265750548967038620449
public exponent:
65537
Validity: [From: Sun Dec 31 16:00:00 PST 1995,
               To: Thu Dec 31 15:59:59 PST 2020]
Issuer: [email protected], CN=Thawte Personal Basic CA, O
U=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western
Cape, C=ZA
SerialNumber: [0]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
Algorithm: [MD5withRSA]
Signature:
0000: 2d e2 99 6b b0 3d 7a 89 d7 59 a2 94 01 1f 2b dd ...k..z..Y......
0010: 12 4b 53 c2 ad 7f aa a7 00 5c 91 40 57 25 4a 38 .KS.........W.J8
0020: aa 84 70 b9 d9 80 0f a5 7b 5c fb 73 c6 bd d7 8a ..p........s....
0030: 61 5c 03 e3 2d 27 a8 17 e0 84 85 42 dc 5e 9b c6 a..........B....
0040: b7 b2 6d bb 74 af e4 3f cb a7 b7 b0 e0 5d be 78 ..m.t..........x
0050: 83 25 94 d2 db 81 0f 79 07 6d 4f f4 39 15 5a 52 .......y.mO.9.ZR
0060: 01 7b de 32 d6 4d 38 f6 12 5c 06 50 df 05 5b bd ...2.M8....P....
0070: 14 4b a1 df 29 ba 3b 41 8d f7 63 56 a1 df 22 b1 .K.....A..cV....
This is a cert =[
Version: V3
Subject: CN=*.mercurypay.com, OU=Comodo PremiumSSL Wildcard, OU=Information Te
chnology, O=Mercury Payment Systems, STREET="72 Suttle Street, Suite M", L=Duran
go, ST=Colorado, POSTALCODE=81303, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
12552582405364904122368800557136600883426046147697390022111207038948008845421116
97612139262756746187884552197255250066841576447434719408180546101657839553295002
41981704931093809205287106190471023650551952772636758926085360687310943371751673
005150920927008661377022502832804963301450995642354061325253865423063
public exponent:
65537
Validity: [From: Thu Feb 01 16:00:00 PST 2007,
               To: Wed Mar 12 15:59:59 PST 2008]
Issuer: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUS
T Network, L=Salt Lake City, ST=UT, C=US
SerialNumber: [69293248245822231088475549727641695166]
Certificate Extensions: 9
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
[2]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[accessMethod: 1.3.6.1.5.5.7.48.2
accessLocation: URIName: http://crt.comodoca.com/UTNAddTrustServerCA.crt, access
Method: 1.3.6.1.5.5.7.48.2
accessLocation: URIName: http://crt.comodo.net/UTNAddTrustServerCA.crt]]
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: c6 3a 32 8e d4 44 8f 6f 46 ff d9 db a7 48 6d 45 ..2..D.oF....HmE
0010: 62 78 25 a2                                        bx..
[5]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
        1.3.6.1.5.5.7.3.1       1.3.6.1.5.5.7.3.2]
[6]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: a1 72 5f 26 1b 28 98 43 95 5d 07 37 d5 85 96 9d .r.....C...7....
0010: 4b d2 c3 45                                        K..E
[7]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
   SSL client
   SSL server
[8]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
PolicyInformation: [
        CertPolicyId: 1.3.6.1.4.1.6449.1.2.1.3.4
        PolicyQualifiers: [PolicyQualifierInfo: [
CPSuri: [
        object identifier: 1.3.6.1.5.5.7.2.1
        uri: https://secure.comodo.net/CPS]
[9]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
2 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.comodoca.com/UTN-USERFirst
-Hardware.crl]
        Reason Flags: null
        Issuer: null
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.comodo.net/UTN-USERFirst-H
ardware.crl]
        Reason Flags: null
        Issuer: null
Algorithm: [SHA1withRSA]
Signature:
0000: 40 b2 e3 1d 81 d4 74 9b 1d cb ca c3 e9 6e 4f 5b ......t......nO.
0010: 54 9a 86 bf 53 4a d6 72 8d 88 e6 ff a9 03 ea 0a T...SJ.r........
0020: dd a4 f7 fc 21 ed 6a 4f f9 a1 d4 7a b2 da fc fb ......jO...z....
0030: bb a3 ab 8a a7 54 00 2a 12 dd e3 d6 29 96 42 d5 .....T........B.
0040: 9a e0 3e 1b 4e da 0e b6 5b 56 51 bd 63 f6 fe 62 ....N....VQ.c..b
0050: eb d3 5e 9f fb 71 7b 09 d0 ef 98 06 55 76 56 8b .....q......UvV.
0060: 9b a0 d9 c8 8a c3 fd df f9 81 39 16 65 1e 2e ac ..........9.e...
0070: 1c e5 b8 a6 76 ef 7b 18 50 d9 cd a1 cc 31 f3 d4 ....v...P....1..
0080: 79 f0 63 95 e7 97 15 28 c3 c6 2a 23 9d 62 08 f4 y.c..........b..
0090: 4b bd 23 eb 8d 72 7d 4b a9 49 83 63 fb 65 b7 b8 K....r.K.I.c.e..
00a0: 96 d8 13 2c 54 f2 11 7c 7d 30 55 f4 0e aa 13 eb ....T....0U.....
00b0: 83 bf ea 22 86 2a d8 4c db a6 21 b4 ce fd 0a 7d .......L........
00c0: bb 65 a5 a7 8f eb 84 1d 8c 3b c7 11 87 e2 06 ab .e..............
00d0: 64 24 ae 48 7c 28 77 db 78 0e a8 b4 a9 32 ff 15 d..H..w.x....2..
00e0: a0 64 65 18 f3 a3 30 3d 9e ed 8d 29 a4 a0 a1 61 .de...0........a
00f0: 3b 86 e2 36 dd 4b fc c9 92 36 e4 be 20 89 cc ab ...6.K...6......
This is a cert =[
Version: V3
Subject: CN=*.pinsprepaid.com, OU=PayGo Web Certificate, O=Test Network,
L=San Diego, ST=California, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
16285445822297696212633924794811890815794019787240551300464692045229173045293235
50230392745826419206436177596443014635997679083703668232616210082740759395739089
19454275822427538242285978316988871614402763162307764241796571858989037339686419
365958906689885958381857638860003924094925916555184457276424623285201
public exponent:
65537
Validity: [From: Sat Dec 29 20:23:42 PST 2007,
               To: Fri Dec 24 20:23:42 PST 2027]
Issuer: CN=*.pinsprepaid.com, OU=PayGo Web Certificate, O=Test Network, L
=San Diego, ST=California, C=US
SerialNumber: [10665365584614926415]
Certificate Extensions: 3
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: a0 28 c8 12 0d dd 40 13 f5 22 d7 b6 c9 eb 42 ae ..............B.
0010: e1 14 66 94                                        ..f.
[CN=*.pinsprepaid.com, OU=PayGo Web Certificate, O=Test Network, L=San Dieg
o, ST=California, C=US]
SerialNumber: [10665365584614926415]
[2]: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
[3]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: a0 28 c8 12 0d dd 40 13 f5 22 d7 b6 c9 eb 42 ae ..............B.
0010: e1 14 66 94                                        ..f.
Algorithm: [SHA1withRSA]
Signature:
0000: 9c 44 24 18 34 24 f7 74 87 24 96 60 44 83 e8 db .D..4..t....D...
0010: 1b ee 83 e9 e1 c3 56 7b 26 2f e3 5a 61 47 89 08 ......V....ZaG..
0020: ba 90 53 93 bd fa 4b bf d4 8e d3 f4 73 33 25 88 ..S...K.....s3..
0030: f1 03 33 03 b8 58 51 7f d0 e3 6c e5 52 6a 7e 13 ..3..XQ...l.Rj..
0040: b1 a6 fc 0a 35 0f c1 0f 5f cd 98 e3 15 34 3b 01 ....5........4..
0050: 4d 97 c4 46 f7 dc 4a 88 ac f8 9a a1 ed d7 2d 62 M..F..J........b
0060: d8 1b af 22 3c 80 af f1 d5 11 b0 b4 05 c8 31 71 ..............1q
0070: d5 dd 4a 42 d1 4c 97 f3 18 74 77 5f 0b 9b 10 7d ..JB.L...tw.....
This is a cert =[
Version: V3
Subject: CN=secure1.galileoprocessing.com, OU=Production, O=Galileo Processing
Inc., L=West Bountiful, ST=Utah, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
16585272136129690466708620936482853429710701504038078236367586054432000828333691
71917574804367890152416144664864739837342571709183400677965661645849511638944496
97747864586117452849688436666474856963873439961969030395107131294137520076094597
149589721904600686262918653808018055505396653031945227384584896096387
public exponent:
65537
Validity: [From: Mon Jan 14 16:00:00 PST 2008,
               To: Mon Feb 28 15:59:59 PST 2011]
Issuer: [email protected], CN=Thawte Premium Server CA, O
U=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Weste
rn Cape, C=ZA
SerialNumber: [165265921466827562370348155546990963259]
Certificate Extensions: 4
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[accessMethod: 1.3.6.1.5.5.7.48.1
accessLocation: URIName: http://ocsp.thawte.com]]
[2]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
[3]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
1 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.thawte.com/ThawteServerPre
miumCA.crl]
        Reason Flags: null
        Issuer: null
[4]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
        1.3.6.1.5.5.7.3.1       1.3.6.1.5.5.7.3.2]
Algorithm: [SHA1withRSA]
Signature:
0000: 81 c0 8d bd d5 b7 6f 7f eb fc 93 33 c3 aa 0d 6f ......o....3...o
0010: d9 36 30 c9 af a0 01 a9 dd 75 1a 45 34 60 47 6f .60......u.E4.Go
0020: cb 52 65 8c 91 e6 f8 38 91 91 46 00 9f 4d 78 42 .Re....8..F..MxB
0030: 9f bf 4a 4e ff 63 cb 18 6f 6e 88 26 4e da e0 73 ..JN.c..on..N..s
0040: ed 49 4a e2 ab dc 01 db 3d fe 4c d7 99 1c 23 23 .IJ.......L.....
0050: f8 24 54 5b a0 bf 27 57 4c 0a f0 8e 3e 58 3f 5c ..T....WL....X..
0060: 03 da 09 0a 29 f2 f5 99 2b b0 da 0e 82 5b 18 cb ................
0070: 39 bd 14 91 62 ac 83 8a b9 b6 8c a4 e0 d9 fd e3 9...b...........
This is a cert =[
Version: V3
Subject: CN=*.questps.com.au, OU=Operations, O=Quest Payment Systems, L=Hawtho
rn, ST=Victoria, C=AU
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
13927401538401051481741625165099229029681926680820373629686880750356955603275739
35404946995026390516720126110345930925847480302939279377134754082062263865742071
20957396443715719965192780351342785833080978234789409963603439531488192089117237
143472365458965132391280159287801210635522967328773863585549974229739
public exponent:
65537
Validity: [From: Sun Jul 15 23:15:18 PDT 2007,
               To: Tue Jul 15 23:15:18 PDT 2008]
Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
SerialNumber: [506317]
Certificate Extensions: 5
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 48 e6 68 f9 2b d2 b2 95 d7 47 d8 23 20 10 4f 33 H.h......G....O3
0010: 98 90 9f d4                                        ....
[2]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
1 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.geotrust.com/crls/secureca
.crl]
        Reason Flags: null
        Issuer: null
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Non_repudiation
Key_Encipherment
Data_Encipherment
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 0a 69 ce 61 f9 da 96 c8 b5 f9 36 81 43 f6 75 fb .i.a......6.C.u.
0010: e4 14 2f 0e                                        ....
[5]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
        1.3.6.1.5.5.7.3.1       1.3.6.1.5.5.7.3.2]
Algorithm: [SHA1withRSA]
Signature:
0000: 45 66 89 34 af 71 dc b1 fe 20 54 15 54 e8 9e b4 Ef.4.q....T.T...
0010: 75 da 1c 64 c3 9d e9 d7 91 99 a5 e6 50 88 2f 83 u..d........P...
0020: cb 14 e5 e1 5a 66 21 68 f3 2b 23 54 61 8e 88 95 ....Zf.h...Ta...
0030: ec b1 f3 86 d4 c3 3e c2 ee 09 25 78 fa f1 74 dc ...........x..t.
0040: a4 d2 73 14 7a 51 f0 82 9e 1f 93 00 f3 f0 94 b5 ..s.zQ..........
0050: c0 ba 48 9c 86 5f 5b 74 fd 8c 81 83 a7 35 27 cb ..H....t.....5..
0060: 31 3b e6 e8 3b b7 3c 26 fb 4e 4d 30 5e 32 e5 da 1........NM0.2..
0070: 83 e8 8c f9 3e 84 09 04 6d 61 40 ea 08 e7 ff c7 ........ma......
This is a cert =[
Version: V1
Subject: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="
(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O
="VeriSign, Inc.", C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
22096661060012873855689347974161418916763510073523357926358326864792592503123173
99490819292635395781267090128441774779218884243225403432375392329269925111338044
19877348645492891283661498502893173840787837475108926513618176408123228217171508
48579148188498107741752990085073340007737937361627542392633585717193577428778849
70689954598075001332363158305018470088291940060537606809254674162830802015825390
73549038990262947134158436810352799408298755647856794057801047782628775050960576
78977556854174242282489588564651152454691261263722936464927601734981930340276221
549179112855447214959676835981467313741947570713364283017
public exponent:
65537
Validity: [From: Thu Sep 30 17:00:00 PDT 1999,
               To: Wed Jul 16 16:59:59 PDT 2036]
Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(
c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O=
"VeriSign, Inc.", C=US
SerialNumber: [129520775995541613599859419027715677050]
Algorithm: [SHA1withRSA]
Signature:
0000: 34 26 15 3c c0 8d 4d 43 49 1d bd e9 21 92 d7 66 4.....MCI......f
0010: 9c b7 de c5 b8 d0 e4 5d 5f 76 22 c0 26 f9 84 3a .........v......
0020: 3a f9 8c b5 fb ec 60 f1 e8 ce 04 b0 c8 dd a7 03 ................
0030: 8f 30 f3 98 df a4 e6 a4 31 df d3 1c 0b 46 dc 72 .0......1....F.r
0040: 20 3f ae ee 05 3c a4 33 3f 0b 39 ac 70 78 73 4b .......3..9.pxsK
0050: 99 2b df 30 c2 54 b0 a8 3b 55 a1 fe 16 28 cd 42 ...0.T...U.....B
0060: bd 74 6e 80 db 27 44 a7 ce 44 5d d4 1b 90 98 0d .tn...D..D......
0070: 1e 42 94 b1 00 2c 04 d0 74 a3 02 05 22 63 63 cd .B......t....cc.
0080: 83 b5 fb c1 6d 62 6b 69 75 fd 5d 70 41 b9 f5 bf ....mbkiu..pA...
0090: 7c df be c1 32 73 22 21 8b 58 81 7b 15 91 7a ba ....2s...X....z.
00a0: e3 64 48 b0 7f fb 36 25 da 95 d0 f1 24 14 17 dd .dH...6.........
00b0: 18 80 6b 46 23 39 54 f5 8e 62 09 04 1d 94 90 a6 ..kF.9T..b......
00c0: 9b e6 25 e2 42 45 aa b8 90 ad be 08 8f a9 0b 42 ....BE.........B
00d0: 18 94 cf 72 39 e1 b1 43 e0 28 cf b7 e7 5a 6c 13 ...r9..C.....Zl.
00e0: 6b 49 b3 ff e3 18 7c 89 8b 33 5d ac 33 d7 a7 f9 kI.......3..3...
00f0: da 3a 55 c9 58 10 f9 aa ef 5a b6 cf 4b 4b df 2a ..U.X....Z..KK..
This is a cert =[
Version: V3
Subject: [email protected], CN=Thawte Personal Premium
CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Wes
tern Cape, C=ZA
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: IBMJCE RSA Public Key:
modulus:
14142912792453816926684060849225594563491048166366460724276985519259966555971678
52869379882523038078369899938721755934187919620921836179968420049065941827306142
30211575508893419840570952601082644441415731845520305432484883710755881614381726
656557001768827822997905802020222847103928452492333928687906770815093
public exponent:
65537
Validity: [From: Sun Dec 31 16:00:00 PST 1995,
               To: Thu Dec 31 15:59:59 PST 2020]
Issuer: [email protected], CN=Thawte Personal Premium C
A, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=West
ern Cape, C=ZA
SerialNumber: [0]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
Algorithm: [MD5withRSA]
Signature:
0000: 69 36 89 f7 34 2a 33 72 2f 6d 3b d4 22 b2 b8 6f i6..4.3r.m.....o
0010: 9a c5 36 66 0e 1b 3c a1 b1 75 5a e6 fd 35 d3 f8 ..6f.....uZ..5..
0020: a8 f2 07 6f 85 67 8e de 2b b9 e2 17 b0 3a a0 f0 ...o.g..........
0030: 0e a2 00 9a df f3 14 15 6e bb c8 85 5a 98 80 f9 ........n...Z...
0040: ff be 74 1d 3d f3 fe 30 25 d1 37 34 67 fa a5 71 ..t....0..74g..q
0050: 79 30 61 29 72 c0 e0 2c 4c fb 56 e4 3a a8 6f e5 y0a.r...L.V...o.
0060: 32 59 52 db 75 28 50 59 0c f8 0b 19 e4 ac d9 af 2YR.u.PY........
0070: 96 8d 2f 50 db 07 c3 ea 1f ab 33 e0 f5 2b 31 89 ...P......3...1.
This is a cert =[
Version: V3
Subject: CN=*.backuppay.com, OU=Comodo PremiumSSL Wildcard, OU=Information Tec
hnology, O=Mercury Payment Systems, STREET="72 Suttle, Suite 'M'", L=Durango, ST
=Colorado, POSTALCODE=81303, C=US
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: IBMJCE RSA Public Key:
modulus:
13600061469090500423648422271274026009793773824200084939450792307466414518281905
78915137508617752173548436692455079898861149850144087985398167558687604694824219
94042711833635299385450526613233517165581563624887506491771190814673785574365279
979908619877143128523889569350716633683176043911091941941182416621337
public exponent:
65537
Validity: [From: Thu Feb 01 16:00:00 PST 2007,
               To: Wed Mar 12 15:59:59 PST 2008]
Issuer: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUS
T Network, L=Salt Lake City, ST=UT, C=US
SerialNumber: [291946271077116231447010286015885314245]
Certificate Extensions: 9
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
[2]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
[accessMethod: 1.3.6.1.5.5.7.48.2
accessLocation: URIName: http://crt.comodoca.com/UTNAddTrustServerCA.crt, access
Method: 1.3.6.1.5.5.7.48.2
accessLocation: URIName: http://crt.comodo.net/UTNAddTrustServerCA.crt]]
[3]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_Encipherment
[4]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: c1 a6 cc 48 48 b5 ed 73 ef 0a cd 2c 29 4c 62 b4 ...HH..s.....Lb.
0010: d0 ab bf 6e                                        ...n
[5]: ObjectId: 2.5.29.37 Criticality=false
ExtKeyUsage [
        1.3.6.1.5.5.7.3.1       1.3.6.1.5.5.7.3.2]
[6]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: a1 72 5f 26 1b 28 98 43 95 5d 07 37 d5 85 96 9d .r.....C...7....
0010: 4b d2 c3 45                                        K..E
[7]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
   SSL client
   SSL server
[8]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
PolicyInformation: [
        CertPolicyId: 1.3.6.1.4.1.6449.1.2.1.3.4
        PolicyQualifiers: [PolicyQualifierInfo: [
CPSuri: [
        object identifier: 1.3.6.1.5.5.7.2.1
        uri: https://secure.comodo.net/CPS]
[9]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
2 CRL Distribution Points:
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.comodoca.com/UTN-USERFirst
-Hardware.crl]
        Reason Flags: null
        Issuer: null
Distribution Point: [
        Distribution Point Name: [URIName: http://crl.comodo.net/UTN-USERFirst-H
ardware.crl]
        Reason Flags: null
        Issuer: null
Algorithm: [SHA1withRSA]
Signature:
0000: a6 e4 56 7a 01 79 c3 28 2a b5 ad ae 58 0c 7c de ..Vz.y......X...
0010: bc a2 b7 85 e2 98 e1 18 c5 53 9e 20 bf e8 8f f2 .........S......
0020: 5e cc 1b 8c 86 47 e4 9d 4e 18 16 91 77 c6 05 7f .....G..N...w...
0030: d8 50 4b 94 09 8b ff 64 4b 90 8c 64 4a 78 b3 cb .PK....dK..dJx..
0040: d0 3f 46 65 e2 38 a3 0f c5 31 d1 2a c4 37 51 a7 ..Fe.8...1...7Q.
0050: 9a 47 d6 03 0b 48 50 6c 5a a2 5d 4f af 8f 6a 77 .G...HPlZ..O..jw
0060: 78 9f 71 a9 c7 8c ae e2 23 f4 2a 4b 48 e0 05 46 x.q........KH..F
0070: 4a 88 99 5f ca ef 09 95 f7 d4 37 6f 4a 4a 13 86 J.........7oJJ..
0080: 41 15 74 80 02 a8 02 80 29 fc 6d d6 e0 d3 a2 ad A.t.......m.....
0090: d9 4d ec 25 c3 a0 83 26 0f 7f b5 3d 7d 6f 0d 9a .M...........o..
00a0: 2e ab f3 cb 8b 5c d0 18 e3 20 bc 22 97 b6 a0 45 ...............E
00b0: 8a d0 0c f9 d9 1c 77 6e 17 ee 30 8f 5e 9e 7d c1 ......wn..0.....
00c0: d4 77 44 8e 3a 3a 7f ee ee e1 7b 1b 32 81 01 a8 .wD.........2...
00d0: 62 7e 82 55 be 6c 73 d3 12 a4 23 ab b9 ef ad 5a b..U.ls........Z
00e0: 73 7b 28 05 37 d9 69 13 8a 7a d4 31 e8 02 39 6f s...7.i..z.1..9o
00f0: ac f9 aa 5f b4 ea bd de 87 03 ee fb b0 80 16 49 ...............I
This is a cert =[
Version: V3
Subject: [email protected], CN=64.47.55.17, OU=MI
S, O=Cabelas Inc, L=Sidney, ST=Nebraska, C=US
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: IBMJCE RSA Public Key:
modulus:
13768870705676032884943158948133086707130963695630252713762741898658183420051882
41914160772118669025761340096644368492520897452521291473029710155067231617758619
45693847182035381145540493930157142197837425711697611478316115600616533780363229
520298453203636612811789291165305298410647569530743837859826680773901
public exponent:
65537
Validity: [From: Thu Oct 05 08:36:55 PDT 2006,
               To: Su

Similar Messages

Tip for Mail certificates not being honored for parked domains

I was having trouble with certificates not being honored, such that when my imap mail was being checked I constantly had the warning box come up to tell me the certificate was not valid. I would show the certificate, tell it to be trusted always, and yet I'd still see the triangle warning next to my inbox, and have trouble connecting. Then I saw a post about having multiple domains pointed to the same server, so I forwarded from one domain to the other and now the certificate is honored.
The other domain I had was parked at the same domain by my host, so the underlying imap server domain was the same for both. That must have caused a conflict in having both certificates be honored, and indeed only one of them at a time would work. Deleting one of the accounts solved the problem, though I had to set up forwarding to bring all my mail from one to the other.
While the problem is solved, it seems like there ought to be a way that I can have mail to my main domain and parked domain using the same underlying domain imap server not cause this conflict, but in the meantime I'll just have to forward from the parked to the main domain.
Just wanted to share the solution here.

Alex Thanks for the reply
my entry in amavisd.conf reads as follows:
@localdomainsmaps = ( [".$mydomain"] ); # list of all local domains
I thought this was supposed to pick up all the local aliases?
What does changing to ( 1 ); do differently to above??
TIA
Tony

When a site asks for a client certificate, not all certificates are presented.

At www.pkiuniversity.com/sandbox/index.php, I am asked for a client certificate. I get to choose from a list of the certificates issued by startcom but not my own. The extended key usage does mark it for client authentication. The root certificate corresponding to the signing private key is also in the store. Why don't these certificates pop up. They do in Safari.

If you're interested, I get my certificate from
reloid.com/enrollments/cheapcerts3/getcert.php?email=[email protected]
This is designed to be a very insecure certificate with no chance of being added to the built-in cache.

HTTPS connection with client certificate not working in spartan

Spartan does not show certificate for the user to select
when I click the https link.
The certificates (taken from a smartcard) are indeed present in the user CertStore.
It works with IE 11 and Chrome.
Has somebody any suggestions ?
Thanks.

in fact you are more using a reverse-proxy than a proxy since it is on the server part..
You have to put all the SSL server part on the reserve-proxy itself and not on the final RSS feed. Then, the reverse-proxy will authenticate your client and gets its certificate. After that, either this proxy will open a plain connection (no ssl) towards the RSS, or you can also open a ssl connection but this means you must create a client certificate for the proxy. It just depends on the security level you need, and I used this solution many times in professional hosting.
hope it helps !

Multiple Exchange accounts and client certificates not working...?

Hi all,
I have a problem with my company iPad's. I'm trying to configure 2 Exchange accounts with certificate based authentication on my iPad with the iPhone config utility. For that i have created 2 client certificates.
When I configure just 1 mailbox, does not matter which one of the 2, with the iPhone config util, it al works ok with client authentication.
When I configure 2 mailboxes, on the iPad, without client certificate authentication it al works ok.
When I configure 2 mailboxes with the 2 client certificates with the iPhone config util, both exchange accounts have the same mailbox. When I configure for example mailbox Jim and Harry with the corresponding certificates and I load it into the iPad. The exchange account of Jim has Jim his mailbox, but the exchange account of Harry also has the mailbox of Jim. And sometimes it is vice versa.....
Can anybody help me in this, we are using 4th gen iPad with MS Exchange ActiveSync 2003 SP2 en MS Forefront TMG with Kerberos delegation.
Please advice.
Cheers,
Eddy

Hi Eddy,
I have the feeling that the SSL connection after being established is only using the first authenticated certificated to connect to the exchange server.
Have you had a look over this Microsoft page:
http://technet.microsoft.com/en-us/magazine/ff472472.aspx
Are you able to test 2 accounts on one pad in a test environment preferably with SSL inspection off?
Do you have any information in the Forefront logs of the users being authenticated from the iPad? Or is one user authenticated twice?
Cheers,
IhalpU

Godaddy SSL certificate installation problems - intermediate certificate not being recognized

domain = mail.gottfried.org
Installed both the certificate and the intermediate certificate from godaddy (used the 10.6 mac os x version)
Response from:
http://www.sslshopper.com/ssl-checker.html#hostname=mail.gottfried.org
The certificate is not trusted in all web browsers. You may need to install an Intermediate/chain certificate to link it to a trusted root certificate. Learn more about this error. You can fix this by following GoDaddy's Certificate Installation Instructions for your server platform. Pay attention to the parts about Intermediate certificates.
When I check in 0000_any_443_.conf
I see:
SSLCertificateFile "/etc/certificates/mail.gottfried.org.1E5F3C903B64E78E3241929B16F616D1DDD130FE. cert.pem
SSLCertificateKeyFile "/etc/certificates/mail.gottfried.org.1E5F3C903B64E78E3241929B16F616D1DDD130FE. key.pem
SSLCertificateChainFile "/etc/certificates/mail.gottfried.org.1E5F3C903B64E78E3241929B16F616D1DDD130FE. chain.pem
I am assuming that the intermediate certificate should be:
mail.gottfried.org.1E5F3C903B64E78E3241929B16F616D1DDD130FE.chain.pem
When I look at that certicate it is the same as
mail.gottfried.org.1E5F3C903B64E78E3241929B16F616D1DDD130FE.cert.pem
When I check keychain and exported both the mail.gottfried.org certificate and also the starfield secure certification authority they match what was installed initially (what I downloaded from Godaddy).
It looks like in the install process the intermediate certificate is not being linked to the ssl certificate and that the ssl certificate is being used for the chain.
Anyone have any suggestions?
I have talked to both Godaddy and Apple Enterprise support. Godaddy has nothing past 10.6 instruction wise (though the support person really tried to help). The Apple rep couldnt really help and if I really want help from them I need to talk to integration where costs start at $700....
Anyone have an SSL provider that worked properly with 10.8 or has really good support for mountain lion server?
Please let me know.
Thanks!

While you still can, get a refund for the certificate, and get a certificate from somebody else, and preferably one that doesn't need an intermediate? That'll be the easiest.
If you're not doing ecommerce or otherwise dealing with web browsers and remote clients that you don't have some control over or affiliation with, you can use a private certificate and get equivalent (or arguably better) security. Running your own certificate authority does mean you'll learn more about certificates, though.
Here and here are general descriptions of getting certificates and intermediate certificates loaded, and some troubleshooting here and particularly here (TN2232). I have found exiting Keychain Access to be a necessary step on various versions. It shouldn't be, but...
FWIW and depending on your particular DNS setup and whether you're serving multiple web sites, you'll need a multiple-domain certificate.
Full disclosure: I've chased a few of these cases around for customers, and it can take an hour or three to sort out what the particular vendor of math, err, certificates has implemented, to confirm the particular certificate formats and possibly convert the certificates where necessary, and to generally to sort out the various posted directions and confusions. (I'm not particularly fond of any of the major math, err, certificate vendors, either.)

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.

Mac Client Certificate not found

Hey all, i'm trying to install the ConfigMgr client on a mac system. The site is 2012 SP1 RTM however since there is no release yet of the mac client i'm using the mac client install from the SP1 beta install folder (Suggested by Microsoft)
I followed the instructions on how to install clients on mac computer from technet. Everything from the install and the enrollment seems to complete fine no errors. After the enrollment when I open System Preferences > Configuration Manager it says "Certificate
not found" If i check the ccmclient log file on the mac it shows the following errors
Failed to Parse MgmtAuthority ServerList
Failed to get server list
Failed to GetProperty Mode from Configuration Provider : 80070490
Requested certificates not available in store
Certificate not found in store. Bailing out!
Failed to validate certificate
The certificate shows up under system in the keychain, the only strange thing is it shows for name the user who enrolled in the certificate. I figured it should have showed the system name. The root ca is also there. Any help would be appreciated, thanks

Okay so figured this out, and i'll post in case this happens to someone else. The certificate will always show under the keychain with a name of whoever the user was that did the enrollment. So if you used Joe Smith, then the certificate will be called
Joe Smith. In my case the account I used to enroll had a active directory display name of two words such as "Joe Smith" Because of this space in between, configuration manager client kept listing the certificate as "Joe". I was then realized that indeed just
like the error said the certificate could not be found because its looking for Joe and the the certificate says Joe Smith. The fix was instead do the enrollment with a normal account with no spacing in the name. This may be a bug or Microsoft may not recommend
creating AD accounts with display names with spaces.

SOAP Axis adapter_Encryption via Client Certificate not working

Dear Experts,
Could anyone please share the steps to enable encryption via client certificate in SOAP AXIS receiver adapter.
I am able to do the same using normal SOAP adapter but with AXIS framework the steps are not working.
I have come across few sdn links to configure axis framework for authentication using wsse security standard but this seems to be different as it requires user and password whereas with certificates we are not given any user/password.
Please provide some valuable inputs.
Thanks.

Hi Shikha,
see the -
Advanced Usage Questions
8. How can I configure a channel to use the encryption and ....
of the FAQ attached to the note -
1039369 - FAQ XI Axis Adapter
Regards
Kenny

Some client data not being populated after upgrading to NCS 1.1.0.58

After upgrading to Cisco Prime NCS 1.1.0.58 some of the client data is not being populated or gathered. The graphs labeled "Client Count By Association/Authentication" and "Client Count By Wireless/Wired" are no longer being updated? Not sure what was changed during the upgrade or where to look to get it to start collecting the data again?

Eajackson,
Make sure your WLC, MSE and WCS/NCS code matches the compatibility matrix here:
http://www.cisco.com/en/US/docs/wireless/controller/5500/tech_notes/Wireless_Software_Compatibility_Matrix.html
Sent from Cisco Technical Support iPhone App

X.509 client certificate not working through Reverse proxy

Dear expert,
We are working on fiori infrastructure. Our current scope is to enable X.509 authentication for both internet and intranet. However, the intranet scenario for X.509 authentication is working fine but internet is not, we got error message of "Base64 decoding of certificate failed". For landscape, the only difference between internet and intranet is we have apache reverse proxy in DMZ. We are using gateway as fron-end server, business suite and HANA in the back-end.
As X.509 authentication works fine under intranet scenario, we assume that the configuration for X.509 for both front-end and back-end are correct. With that assumption, the issue would exist in reverse proxy. We are using apache 2.4.7 with openssl 1.0.1e, but we have upgraded the openssl to the latest version 1.0.1h for SSL certificate generation. Below are the apache configuration for X.509.
Listen 1081
<VirtualHost *:1081>
SSLEngine on
SSLCertificateFile "D:/Apache24/conf/server.cer"
SSLCertificateKeyFile "D:/Apache24/conf/server.key"
SSLCertificateChainFile "D:/Apache24/conf/server-ca.cer"
SSLCACertificateFile "D:/Apache24/conf/client-ca.cer"
SSLVerifyClient optional
SSLVerifyDepth 10
SSLProxyEngine On
SSLProxyCACertificateFile "D:/Apache24/conf/internal-ca.cer"
SSLProxyMachineCertificateFile "D:/Apache24/conf/server.pem"
AllowEncodedSlashes On
ProxyPreserveHost on
RequestHeader unset Accept-Encoding
<Proxy *>
     AddDefaultCharset Off
     SSLRequireSSL
     Order deny,allow
     Allow from all
</Proxy>
RequestHeader set ClientProtocol https
RequestHeader set x-sap-webdisp-ap HTTPS=1081
RequestHeader set SSL_CLIENT_CERT ""
RequestHeader set SSL_CLIENT_S_DN ""
RequestHeader set SSL_CLIENT_I_DN ""
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s"
RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s"
RequestHeader set SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s"
ProxyPass / https://ldcinxd.wdf.sap.corp:1081/ nocanon Keepalive=on
proxyPassReverse / https://ldcinxd.wdf.sap.corp:1081/
We are out of mind on how to resolve this issue. Please kindly help if you have any idea on it.
thanks,
Best regards,
Xian' an

Hi Samuli,
Really thanks for your reply.
Yes, we have tried your suggestion above in the apache configure file above, but when testing the HANA service, we got error message "Certificate could not be authenticated".
Yes, web dispatcher makes the X.509 authentication much easier as under intranet scenario, no DMZ between browser and web dispatcher. Client certificate pass through web dispatcher directly and it works perfectly this way. Not sure why it doesn' t work through apache reverse proxy.
Best regards,
Xian' an

Certificate not being read

Hello all,
We are using Cisco VPN anyconnect mobile 3.1.xx. We are setup that when a user has a VPN certificate installed on the corporate computer it has full access (goes to a particular network subnet) to the network. If no certificate on pc (personal) has limited ( access to another subnet) access to the network. Certificates are only valid for 3 months. Some users work out of the office (with corporate pc) for more than 3 month at a time thus the certificate expires.
We have rectified this by having a site where clients can ask to have a certificate created and downloaded to their computers and thus get the certificate. This works without fail.
Here is my dilema for certain users:
Even though the certificate is replaced, the VPN still seems to not recognise (goes to the wrong subnet) the certificate.
These client also have other VPN clients installed: SonicWall VPN
Any help would be greatly apprciated.
Thanks in advance

This is an issue that will have to be resolved with Adobe customer support. We're all just users here on the forum. Here is a list of phone numbers that might get you the assistance you need.
Adobe Connect Support phone numbers

Google.co.uk will not open due to certificate not being recognised, help

This Connection is Untrusted
You have asked Firefox to connect securely to www.google.co.uk, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

Check the date and time and time zone in the clock on your computer: (double) click the clock icon on the Windows Taskbar.
Check out why the site is untrusted and click "Technical Details" to expand this section.
If the certificate is not trusted because no issuer chain was provided (sec_error_unknown_issuer) then see if you can install this intermediate certificate from another source.
You can retrieve the certificate and check details like who issued certificates and expiration dates of certificates.
*Click the link at the bottom of the error page: "I Understand the Risks"
Let Firefox retrieve the certificate: "Add Exception" -> "Get Certificate".
*Click the "View..." button and inspect the certificate and check who is the <b>issuer of the certificate</b>.
You can see more Details like intermediate certificates that are used in the Details pane.
If <b>"I Understand the Risks"</b> is missing then this page may be opened in an (i)frame and in that case try the right-click context menu and use "This Frame: Open Frame in New Tab".
*Note that some firewalls monitor (secure) connections and that programs like Sendori or FiddlerRoot can intercept connections and send their own certificate instead of the website's certificate.
*Note that it is not recommended to add a permanent exception in cases like this, so only use it to inspect the certificate.

New Wireless clients certificate not verified

Whenever a new clients login using SSID Green,using cisco WLC 4404, there is a prompt saying certificate is not valid. No doubt, clients can connect once they accept the certificate. Is there anyway I can remove this prompt? We have ACS doing authentication.The certificate is signed by authorized bodies? Please advice

I have indeed.
Pushing the profile can happen a few ways. If you use ISE you can push a profile in auto enrollment. Whereby you create the wireless profile (SSID, Security, Add Cert). This is delivered to the user automatically during enrollment.
Another way to make profiles and manually push is with the Apple Configurator.
https://itunes.apple.com/us/app/apple-configurator/id434433123?mt=12
You can also use a tool like Jamf for MACs to make and push profiles.
Hope this helps ..
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
‎"I'm in a serious relationship with my Wi-Fi. You could say we have a connection."
"Im like bacon, I make your wireless better"

Infoobject not being present in MP

Guys,
If there is a multiprovider which has one cube and one master data infoobject. The cube has 0FiscalYear as its time char. However, in Multiprovider, there is nothing under Time Char. Would it be possible for me to use that 0Fiscal year that is present under that cube's time char but not on MP level?
Thanks,
RG

Hello Ram,
Your question isn't very clear to me. Basically, it is all right if you want to use only a selected number of characteristics from the underlying infoproviders in a multiprovider. Others (that you do not include or do not identify from particular infoproviders) are not available for reporting. If your question isn't answered, please specify it more clearly.

Client certificate not being presented by Sun JDK

Similar Messages

Maybe you are looking for