Openfire should ignore Othername formats it doesn't understand


(02:41:10 PM) guus: did anyone generate new certificates with StartSSL recently?
(02:42:05 PM) guus: Openfire chokes on the subject alt. name in it
(02:42:24 PM) guus: X509v3 Subject Alternative Name: <>, <>, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>
(02:43:14 PM) Alex: I have created a new one in January
(02:43:20 PM) Alex: its running n
(02:43:36 PM) guus: given the error message, I'd say that the othername values are something called 'DERTaggedObject', where my server wants a different type
(02:49:13 PM) guus: hmm, yours has simliar: "othername:<unsupported>" entries in Subject altname
(02:50:34 PM) Alex: I am not a X509 expert, maybe dwd can jump onto this
(02:51:19 PM) ***dwd boioings.
(02:51:39 PM) guus: I wonder if it's the openssl tool that can't parse that othername format. I'm far from an export myself :S
(02:51:58 PM) dwd: I think StartTLS^HStartSSL now includes sRVName SANs.
(02:52:31 PM) dwd: Our tools can parse them, and I'd expect any compliant tool which can't to simply ignore them - they're just another form of Othername after all.
(02:52:53 PM) dwd: (And othernames are explcitly designed to be extensible, unlike general names themselves)
(02:54:37 PM) guus: okay, sounds reasonable




Guus der Kinderen
February 9, 2012, 2:06 PM

I just checked in a fix that hides the error. Functionally, it was already ignored (but reported as an error in the logs)

Guus der Kinderen
February 9, 2012, 1:59 PM

This probably relates to the stacktraces that are being logged since using a new server certificate:



Guus der Kinderen


Guus der Kinderen