ADDITIONAL SYSTEM INFORMATION :
OS independent reproducible

A DESCRIPTION OF THE PROBLEM :
We have a certificate with an empty entry in the alternate names object. opensssl outputs:

Unparseable certificate extensions: 1
[1]: ObjectId: 2.5.29.17 Criticality=false
Unparseable SubjectAlternativeName extension due to
java.io.IOException: RFC822Name may not be null or empty

When parsing it in Java, the following exception is caught within the security library and not propagated:

Unparseable certificate extensions: 1
[1]: ObjectId: 2.5.29.17 Criticality=false
Unparseable SubjectAlternativeName extension due to
java.io.IOException: RFC822Name may not be null or empty

Instead, an empty rfc822names list is returned.

I think this behavior is not correct because it renders the application program unable to distinguish between an empty list and an error in the list. As a consequence, our program displays an error that the user's email is missing, and the user is confused because the email is not really missing.

The expected behavior would be to either not catch the exception, so the application program can handle it. Or to return the list excluding the problem entries, yet including the clean entries.





STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
* Create certificate with at least one valid and one empty rfc822 entry at alternate names section
* Try and load the certificate

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected behavior would be to either not catch the exception, so the application program can handle it. Or to return the list excluding the problem entries, yet including the clean entries.

ACTUAL -
An empty list is returned. No exception arrives in the application layer.

CUSTOMER SUBMITTED WORKAROUND :
There is no work-around. The certificate needed to be re-issued without the empty entries. However, due to the misguidance, it took a while to identify the problem.

FREQUENCY : always