I believe you've hit on a dark corner of the X.509 spec. It's weird enough I had to confer with a colleague to make sure I remembered correctly. Some X.509 engines will consult the DN for a component called serialNumber, and, if defined, assign the serialNumber field of the certificate to the value in the DN. I'm uncertain about the behavior if both a serialNumber field and that component appear in the DN. In any case the value in your DN is unusual to say the least:
serialNumber=WmFAfdyKBXDUGJAs8-PFsdcJeu1uPXE- That is the value according to OpenSSL, which I trust unequivocally. RFC2459 requires serialNumber to be an integer. OpenSSL identifies a _different_ value for serial, which is indeed an int: Serial Number: 45016 (0xafd8) I can only infer the exact problem, but I would imagine it is either that the Sun X509 engine can't handle the string in the serialNumber component of the DN, or it's balking because the serialNumber field doesn't match the value parsed from the DN. Bad GeoTrust! I have no idea how to resolve the issue other than to request a new cert with a more reasonable DN, either with an integer value for serialNumber, or without that component altogether. Hopefully those configuration points are under your control. Good luck. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
