Custom OID strange characters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So this leads to the next question:

How do I teach OpenSSL the format of the value for a custom extension without writing code?

I have been poring over man pages and I don?t find anything obvious.

Robert

> On Aug 11, 2015, at 2:24 PM, Wim Lewis <wiml at omnigroup.com> wrote:
> 
> On Aug 11, 2015, at 9:24 AM, Robert Sandilands <rsandila at netscape.net> wrote:
>> I am trying to build a certificate request with a custom OID and it is encoding strange characters in the certificate.
>> 
>> For example I specify the following line in the .cnf file:
>> bla_policy = ASN1:PRINTABLESTRING:blabla
>> Then I get the following when I dump the csr:
>>           1.2.3.4.5.6.7: 
>>                ..blabla
> 
> This is because openssl doesn't know the format of the value of your custom extension.
> 
> Running the result of your script through asn1parse shows the extension section like this (snipped some entries for brevity):
> 
>  417:d=3  hl=2 l=  93 cons:    SEQUENCE          
>  419:d=4  hl=2 l=   9 prim:     OBJECT            :Extension Request
>  430:d=4  hl=2 l=  80 cons:     SET               
>  432:d=5  hl=2 l=  78 cons:      SEQUENCE          
>  434:d=6  hl=2 l=  12 cons:       SEQUENCE          
>  436:d=7  hl=2 l=   3 prim:        OBJECT            :X509v3 Basic Constraints
>  441:d=7  hl=2 l=   1 prim:        BOOLEAN           :255
>  444:d=7  hl=2 l=   2 prim:        OCTET STRING      [HEX DUMP]:3000
>  448:d=6  hl=2 l=  11 cons:       SEQUENCE          
>  450:d=7  hl=2 l=   3 prim:        OBJECT            :X509v3 Key Usage
>  455:d=7  hl=2 l=   4 prim:        OCTET STRING      [HEX DUMP]:030203F8
>  492:d=6  hl=2 l=  18 cons:       SEQUENCE          
>  494:d=7  hl=2 l=   6 prim:        OBJECT            :1.2.3.4.5.6.7
>  502:d=7  hl=2 l=   8 prim:        OCTET STRING      [HEX DUMP]:1306626C61626C61
> 
> 
> Notice that the "value" of each constraint is an OCTET STRING, regardless of its type. (The BOOLEAN field in the basic constraints extension is the Critical flag.) As is usual with X.500 stuff, tracking down the actual definition of this field is a pain, but you can find it in the PKIX RFC3280/5280  (via PKCS#10/RFC2986 and PKCS#9/RFC2985):
> 
>   Extension  ::=  SEQUENCE  {
>        extnID      OBJECT IDENTIFIER,
>        critical    BOOLEAN DEFAULT FALSE,
>        extnValue   OCTET STRING  }
> 
> If you ask asn1parse to dump just the contents of your extension, you'll see exactly the PRINTABLESTRING which you requested:
> 
> % openssl asn1parse -i -offset 504 -length 8 -in test.csr
>    0:d=0  hl=2 l=   6 prim: PRINTABLESTRING   :blabla
> 
> 
> The two bytes, 13 06, are the DER encoding of a 6-byte string (13 contains the tag and class, indicating in this case PRINTABLESTRING, and 06 is the length in bytes of the string which follows). Similarly, the basicConstraints value is an empty (0-length) SEQUENCE because all of its contents have the default values and are omitted; and the keyUsage value is a BIT STRING (tag=3, length=0x02, number of unused bits = 0x03, bits=0x1F once you remove the padding) with a bitmap of the selected constraints. extendedKeyUsage, which I snipped, is a SEQUENCE of OIDs.
> 
> If this is a custom extension, you can define its contents to be whatever you like. The standardized extensions I know about are all DER-encoded values, but I don't think that's an actual requirement.
> 
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux