It looks like OpenSSL always shows "unsupported" for a subjectAltName of
"otherName".

The string that was written (both via M2Crypto, and directly at the
commandline via openssl.cnf):

    1.2.3.4;UTF8:some other identifier

Dumped (openssl x509 -in test.crt -noout -text):

                    c3:88:36:93:82:58:0c:08:7f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                othername:<unsupported>
    Signature Algorithm: sha1WithRSAEncryption
        05:76:d5:fc:d0:44:50:af:39:76:05:b4:cb:b6:99:9f:7c:c0:

Grepping through the OpenSSL source for "otherName", this stood out to me
(in v3_alt.c):

1:

    STACK_OF(CONF_VALUE) *i2v_GENERAL_NAME(X509V3_EXT_METHOD *method,
                    GENERAL_NAME *gen, STACK_OF(CONF_VALUE) *ret)
    {
        unsigned char *p;
        char oline[256], htmp[5];
        int i;
        switch (gen->type)
        {
            case GEN_OTHERNAME:
            X509V3_add_value("othername","<unsupported>", &ret);
            break;

            case GEN_X400:
            X509V3_add_value("X400Name","<unsupported>", &ret);
            break;

            case GEN_EDIPARTY:
            X509V3_add_value("EdiPartyName","<unsupported>", &ret);
            break;

2:

    int GENERAL_NAME_print(BIO *out, GENERAL_NAME *gen)
    {
        unsigned char *p;
        int i;
        switch (gen->type)
        {
            case GEN_OTHERNAME:
            BIO_printf(out, "othername:<unsupported>");
            break;

            case GEN_X400:
            BIO_printf(out, "X400Name:<unsupported>");
            break;

            case GEN_EDIPARTY:
            /* Maybe fix this: it is supported now */
            BIO_printf(out, "EdiPartyName:<unsupported>");
            break;

So, I'm willing to bet that both this and the empirical knowledge coming
from my attempts above mean that I shouldn't ever expect that the
"otherName" values will *ever* be properly rendered via the command-line or
library calls. This might be because they're actual, encoded ASN.1 strings.
So, how can I do it? How do people extract these values? If they are actual
ASN.1 strings, is it up to the developer to decode them?



Dustin

Reply via email to