[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certificate change causing problems
dim memory...isn't there an issue with 2048 certificates on the i
(rather than 1024 certificates)?
On Wed, Feb 9, 2011 at 10:58 AM, Jeff Nickles <jsnickles@xxxxxxxxx> wrote:
>
> A year ago, we experienced problems in HTTPAPI after we were put in a
> position where we had to change our certificate from a class 1 to a
> class 3. After installing the new certificate and making no other
> changes to the application, we received this error:
> "(GSKit) Peer not recognized or badly formatted message received".
> We were not able to get past this issue. Eventually, we were given a
> reprieve and the old class 1 certificate was renewed and the problem
> went away.
> The application using HTTPAPI was written in 2007 and has worked fine
> every year since then. Each year we've renewed the class 1
> certificate and gone about our business. We only have trouble when
> trying to migrate to the class 3 cert style.
> Now, we have little choice but to go to the class 3 cert and the error
> above is again rearing its ugly head. Unfortunately, I'm a novice
> when it comes to certificates so any help is greatly appreciated.
> Here's what we determined last year during our analysis and what we've
> learned this time. Below is a log as well of a recent test.
> We determined last time that gsk_secure_soc_read() is returning the
> 410 error above. This same error is being returned this time. This
> is occurring after posting the initial request chain, but before
> getting to post the application data. The post of the initial request
> chain does not return any error.
> Some traces have been performed and we've been told that the amount of
> data being returned after our initial request chain post is greater
> than 16384. Is this a limit imposed by GSKit or HTTPAPI? Can it be
> changed through a parameter or some other setting or am I even
> thinking of this limit the correct way? I ask this because with the
> class 1 cert style, this error doesn't occur. I guess I'm struggling
> to understand why a simple cert change would cause something like
> this.
> We do use application specific certs and the new cert has been
> associate with our application ID in the DCM. We've tried
> initializing SSL 2.0, SSL 3.0 and TLS 1.0 in HTTPS_INIT, each in turn;
> none of them work.
> Thanks for your help.
> Jeff
> Here's the log.
> HTTPAPI Ver 1.23 released 2008-04-24
> OS/400 Ver V5R4M0
> New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819.
> ProtLoc=0
> https_init(): entered
> ----------------------------------------------------------------------
> ---------------
> Dump of local-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> -----BEGIN CERTIFICATE-----
> MIIE5jCCA86gAwIBAgIQY3ATcjQOia9clOLFMidZSDANBgkqhkiG9w0BAQUFADCB
> 3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV
> UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx
> IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMjAwMDAwMFoX
> DTExMDkwMjIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
> A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlz
> aWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQo
> Yyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTQwMgYDVQQLEytE
> aWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVsbCBTZXJ2aWNlMRowGAYD
> VQQDFBFBYmVyY3JvbWJpZSBGaXRjaDEnMCUGCSqGSIb3DQEJARYYc3NsYWRtaW5A
> YWJlcmNyb21iaWUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5oiXX
> +JIww+86PVy41EKou24Ppq5cHqWn4DnD6nWiBb6vc+7chOCNmO3RD7vC9V/JZJq7
> mWdBJDItvoSetNHFF8nsulXpySaSxSxbtlqWzwwU0CP45RuqgASqZTDJ5AnX3mTw
> h+kopwKtuXhZljfAY5VzHDOxWcnTPpjoiULbfQIDAQABo4HiMIHfMAkGA1UdEwQC
> MAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRw
> czovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAU
> BggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMEoGA1Ud
> HwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24u
> Y29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAVYNZELp3
> l0sd/dudIbZVnSBbMowJ3Yqn2Iv9w548QwWCkC5XSQo8KlGG8wEeXa7YIFY9JVRL
> gIjZpdAf/A4RfsT4J6qdA3+hkDSoXzm0tlYtqYgFdN9/6WMXteKEAf2s4LvtQIG9
> s3E44ZtzS5wG4mK2zgWwkhHr0AsjA/vCq15azRmNJOFharmvquW7AvXiW5i5R90s
> sS4i0IJqTo9Y6UneenB6F6iflPgDkZ1Sd2jNR2+0I0dg66M7atoes6UFrtlwCVfu
> ssotXGKwPH4H6xYsiZNOKFOgRZnLCBG1HhmK5r9vzB0XC8m+GHxxE5v8XbGeFOYJ
> /NpSUmAUXHRcAQ==
> -----END CERTIFICATE-----
> Serial Number: 63:70:13:72:34:0E:89:AF:5C:94:E2:C5:32:27:59:48
> Common Name: Abercrombie Fitch
> Org Unit: VeriSign, Inc.
> Org: Digital ID Class 1 - Microsoft Full Service, OU=Persona Not
> Validated, OU=[1]www.verisign.com/repository/RPA Incorp. by
> Ref.,LIAB.LTD(c)98, OU=VeriSign Trust Network
> Issuer CN: VeriSign Class 1 Individual Subscriber CA - G2
> Issuer Country: US
> Issuer Org: VeriSign, Inc.
> Issuer Org Unit: Persona Not Validated, OU=Terms of use at
> [2]https://www.verisign.com/rpa (c)05, OU=VeriSign Trust Network
> Version: 03
> not before: 20100811190000
> not after: 20110902185959
> pub key alg: 1.2.840.113549.1.1.5
> http_persist_open(): entered
> http_long_ParseURL(): entered
> DNS resolver retrans: 2
> DNS resolver retry : 2
> DNS resolver options: x'00000136'
> DNS default domain: [3]HOMEOFFICE.ANFCORP.COM
> DNS server found: 10.1.4.30
> DNS server found: 10.1.32.50
> DNS server found: 10.15.250.30
> ----------------------------------------------------------------------
> ---------------
> Dump of server-side certificate information:
> ----------------------------------------------------------------------
> ---------------
> Cert Validation Code = 0
> -----BEGIN CERTIFICATE-----
> MIIFizCCBHOgAwIBAgIQIheiqKBkDvvrIC/aRn/iZjANBgkqhkiG9w0BAQUFADCB
> tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
> ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
> YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEvMC0GA1UEAxMm
> VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzIwHhcNMTAwODI2
> MDAwMDAwWhcNMTEwODI2MjM1OTU5WjB4MQswCQYDVQQGEwJVUzERMA8GA1UECBMI
> TmVicmFza2ExDjAMBgNVBAcUBU9tYWhhMR8wHQYDVQQKFBZGaXJzdCBEYXRhIENv
> cnBvcmF0aW9uMQwwCgYDVQQLFANGRFIxFzAVBgNVBAMUDmNhdC5jYWxsaXQuY29t
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvBVVjVIqST/oV2evbtLU
> 5opRKnOvBMDtBGqOsJnU2agIKwZ64y+u4GLhuA5AfivMYb6CGXLfPtTgDa9sPEkA
> EuevE+I4PE2AuijlVw1JFMcZMr70KP5juSZ6jRzghI05/p6GAls73dzwFgbnIS7W
> ne+5OuS+FUeAl6MgldQ9oNgfIv18yjbq0aWTxO4vt1VXl0/vJgTRy3fvw9IcvPVt
> Qr8vsX2MBbAPn1dhWAUYVJE4T7XPsncjrZzVGwDvXXZoTCnlxt/BqwCuGMxGOvZn
> XX7TbfXCl9DwvONtkj2IjsiUHHY0e76Jafi0adsD1tk9wjnBwnSM5hWSUv1fIkgA
> 5QIDAQABo4IB0TCCAc0wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwRQYDVR0fBD4w
> PDA6oDigNoY0aHR0cDovL1NWUlNlY3VyZS1HMi1jcmwudmVyaXNpZ24uY29tL1NW
> UlNlY3VyZUcyLmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYB
> BQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYI
> KwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFKXvCxHOwEEDo0plkEiyHOBX
> LX1HMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy
> aXNpZ24uY29tMEAGCCsGAQUFBzAChjRodHRwOi8vU1ZSU2VjdXJlLUcyLWFpYS52
> ZXJpc2lnbi5jb20vU1ZSU2VjdXJlRzIuY2VyMG4GCCsGAQUFBwEMBGIwYKFeoFww
> WjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweL
> IQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjANBgkq
> hkiG9w0BAQUFAAOCAQEAStUp1W7MphSoexmPEiLf+x35St+WXrXL2BHLS7GIfL9Q
> Pnk9tu8PplJFsLx5Kf56ubOgP4JoIO8MqqBG9ILvXd8mez0NKiwQtsAkD/ByRjlc
> wbGmBCJixHyRaAgzDj3uksGP46XOZEOpvDpbrJIrwwf/+M/wopH7O7qHB28dhKwg
> Sb5mbsvuFn0/4XPcZ493HRqxi+U30bcEd1GYGOgAGka76WZw/XGZ1BqojEh5Y1HC
> vM662PyHxj+DcsIY3KtSPY/FV0W10JU4Xik5s1mkdU/01v/m/serdXALhi3Jd75L
> pfrMRmJPtTKaaF9of1A5xREDfnBTvPs2XifI3i6G1Q==
> -----END CERTIFICATE-----
> Serial Number: 22:17:A2:A8:A0:64:0E:FB:EB:20:2F:DA:46:7F:E2:66
> Common Name: [4]cat.callit.com
> Country: US
> State/Province: Nebraska
> Locality: Omaha
> Org Unit: First Data Corporation
> Org: FDR
> Issuer CN: VeriSign Class 3 Secure Server CA - G2
> Issuer Country: US
> Issuer Org: VeriSign, Inc.
> Issuer Org Unit: Terms of use at [5]https://www.verisign.com/rpa
> (c)09, OU=VeriSign Trust Network
> Version: 03
> not before: 20100825190000
> not after: 20110826185959
> pub key alg: 1.2.840.113549.1.1.5
> Protocol Used: TLS Version 1
> http_persist_post(): entered
> http_long_ParseURL(): entered
> do_post(): entered
> POST /vl/api1c.asp HTTP/1.1
> Host: [6]cat.callit.com
> User-Agent: http-api/1.23
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
> Content-Length: 182
> recvresp(): entered
> (GSKit) Peer not recognized or badly formatted message received.
> ssl_error(410): (GSKit) Peer not recognized or badly formatted message
> received.
> SetError() #44: CommSSL_read: read:(GSKit) Peer not recognized or
> badly formatted message recei
> http_close(): entered
>
> References
>
> 1. http://www.verisign.com/repository/RPA
> 2. https://www.verisign.com/rpa
> 3. http://HOMEOFFICE.ANFCORP.COM/
> 4. http://cat.callit.com/
> 5. https://www.verisign.com/rpa
> 6. http://cat.callit.com/
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------