client certs with no subjectName only SAN

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

client certs with no subjectName only SAN

Robert Moskowitz
There are a number of things I am not clear on, and so far my searching
and reading is coming up short.

If there is no subjectName, only subjectAltName, is the subjectName
still present in the cert only empty or is it totally gone.

I have found that if I put

-subj /

in the openssl req, I end up with an empty subjectName.  Or is there
someway to totally remove this from the cert?

For the subjectAltName, is it suppose to be flagged critical?  I have
seen references of:

subjectAltName=critical,email:[hidden email]

Is this correct and the way to set SAN as critical?

thanks

The cert I have made so far is:

$openssl x509 -noout -text -in $dir/certs/device1.cert.pem
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             c9:8f:b2:7b:e1:95:74:cf
         Signature Algorithm: ED25519
         Issuer: CN = 2001:24:28:14::/64
         Validity
             Not Before: Aug 15 19:51:17 2019 GMT
             Not After : Aug 24 19:51:17 2020 GMT
         Subject:
         Subject Public Key Info:
             Public Key Algorithm: ED25519
                 ED25519 Public-Key:
                 pub:
                     7a:a6:f2:7d:14:8f:fd:a9:55:d9:6f:d6:04:a1:e6:
                     6d:9e:34:1f:d3:2b:59:80:cc:2f:4c:83:4f:81:a0:
                     10:36
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Cert Type:
                 SSL Client, S/MIME
             Netscape Comment:
                 OpenSSL Generated Client Certificate
             X509v3 Subject Key Identifier:
97:B0:DC:A2:74:93:CF:76:5E:82:6C:08:9C:46:73:83:D3:86:8E:9A
             X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

             X509v3 Key Usage: critical
                 Digital Signature, Non Repudiation, Key Encipherment
             X509v3 Extended Key Usage:
                 TLS Web Client Authentication, E-mail Protection
             X509v3 Subject Alternative Name:
                 IP Address:2001:24:28:14:B8AF:2789:CBB9:F7AC
     Signature Algorithm: ED25519
          32:2e:7d:4d:ad:4d:87:4c:57:1a:df:ef:e3:ec:2b:b5:a7:fe:
          2f:48:73:32:72:1a:b6:4a:cd:e4:88:75:98:4d:b0:9a:79:48:
          2b:2c:12:68:0f:c0:86:bd:d9:4e:4b:85:fb:f3:91:68:f4:ec:
          18:99:dd:7e:d5:f8:b6:f0:08:0e

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

OpenSSL - User mailing list
subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"

I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.


Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

Robert Moskowitz


On 8/15/19 4:13 PM, Salz, Rich wrote:
> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"

Fine with me.

> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.

It does seem empty with that -subj / command line option.

I am not seeing subjectName in this dump of the cert:

$    openssl asn1parse -i -in $dir/certs/device1.cert.pem
     0:d=0  hl=4 l= 439 cons: SEQUENCE
     4:d=1  hl=4 l= 361 cons:  SEQUENCE
     8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
    10:d=3  hl=2 l=   1 prim:    INTEGER           :02
    13:d=2  hl=2 l=   9 prim:   INTEGER           :C98FB27BE19574CF
    24:d=2  hl=2 l=   5 cons:   SEQUENCE
    26:d=3  hl=2 l=   3 prim:    OBJECT            :ED25519
    31:d=2  hl=2 l=  29 cons:   SEQUENCE
    33:d=3  hl=2 l=  27 cons:    SET
    35:d=4  hl=2 l=  25 cons:     SEQUENCE
    37:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
    42:d=5  hl=2 l=  18 prim:      UTF8STRING :2001:24:28:14::/64
    62:d=2  hl=2 l=  30 cons:   SEQUENCE
    64:d=3  hl=2 l=  13 prim:    UTCTIME           :190815195117Z
    79:d=3  hl=2 l=  13 prim:    UTCTIME           :200824195117Z
    94:d=2  hl=2 l=   0 cons:   SEQUENCE
    96:d=2  hl=2 l=  42 cons:   SEQUENCE
    98:d=3  hl=2 l=   5 cons:    SEQUENCE
   100:d=4  hl=2 l=   3 prim:     OBJECT            :ED25519
   105:d=3  hl=2 l=  33 prim:    BIT STRING
   140:d=2  hl=3 l= 226 cons:   cont [ 3 ]
   143:d=3  hl=3 l= 223 cons:    SEQUENCE
   146:d=4  hl=2 l=   9 cons:     SEQUENCE
   148:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Basic
Constraints
   153:d=5  hl=2 l=   2 prim:      OCTET STRING      [HEX DUMP]:3000
   157:d=4  hl=2 l=  17 cons:     SEQUENCE
   159:d=5  hl=2 l=   9 prim:      OBJECT            :Netscape Cert Type
   170:d=5  hl=2 l=   4 prim:      OCTET STRING      [HEX DUMP]:030205A0
   176:d=4  hl=2 l=  51 cons:     SEQUENCE
   178:d=5  hl=2 l=   9 prim:      OBJECT            :Netscape Comment
   189:d=5  hl=2 l=  38 prim:      OCTET STRING      [HEX
DUMP]:16244F70656E53534C2047656E65726174656420436C69656E74204365727469666963617465
   229:d=4  hl=2 l=  29 cons:     SEQUENCE
   231:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject Key
Identifier
   236:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX
DUMP]:041497B0DCA27493CF765E826C089C467383D3868E9A
   260:d=4  hl=2 l=  31 cons:     SEQUENCE
   262:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority
Key Identifier
   267:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX
DUMP]:30168014B145189B33826C7429692A15933B1C31D237D6CA
   293:d=4  hl=2 l=  14 cons:     SEQUENCE
   295:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Key Usage
   300:d=5  hl=2 l=   1 prim:      BOOLEAN           :255
   303:d=5  hl=2 l=   4 prim:      OCTET STRING      [HEX DUMP]:030205E0
   309:d=4  hl=2 l=  29 cons:     SEQUENCE
   311:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Extended
Key Usage
   316:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX
DUMP]:301406082B0601050507030206082B06010505070304
   340:d=4  hl=2 l=  27 cons:     SEQUENCE
   342:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject
Alternative Name
   347:d=5  hl=2 l=  20 prim:      OCTET STRING      [HEX
DUMP]:301287102001002400280014B8AF2789CBB9F7AC
   369:d=1  hl=2 l=   5 cons:  SEQUENCE
   371:d=2  hl=2 l=   3 prim:   OBJECT            :ED25519
   376:d=1  hl=2 l=  65 prim:  BIT STRING


Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
Bonjour,

In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical."

It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL.

Cordialement,
Erwann Abalea

Le 15/08/2019 22:13, « openssl-users au nom de Salz, Rich via openssl-users » <[hidden email] au nom de [hidden email]> a écrit :

    subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"
   
    I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

OpenSSL - User mailing list
>    In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical."
   
>    It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL.
 
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 than I ever knew :)

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

Robert Moskowitz


On 8/16/19 7:58 AM, Salz, Rich wrote:
>>     In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical."
>      

I will run another test today and see if it is as easy as claimed to
flag SAN critical.


>>     It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL.

I was wondering more the construction of the cert when 'no
subjectName'.  You confirmed that the object is there. Probably length
0.  I will have to look at that asnparse listing more critically.

>    
> You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 than I ever knew :)
>

Why I ask, perhaps seemingly dumb questions, here.  Those that really
know the stuff are still around.

I learned enough ASN1 to get by with x.509 and snmp and have forgotten
much of what I learned ~20 years ago.  I do have an iana enterprise
number that I used in some of my OID proposals in both way back then.

The failing read access really bites.

thanks both of you.


Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

Viktor Dukhovni
In reply to this post by OpenSSL - User mailing list

> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users <[hidden email]> wrote:
>
> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"

This is wrong.  When the subject DN is empty, the subjectAltName should be
marked as critical.  IIRC some Java implementations reject the certificate
otherwise.

> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.

OpenSSL supports empty (empty RDN sequence) subject DNs.
The "-subj /" option is one way to make that happen.

Empty is of course different from "absent", which is not
possible, since the subject DN is a required component of
an X.509 certificate.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

Robert Moskowitz
Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
>> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users <[hidden email]> wrote:
>>
>> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"
> This is wrong.  When the subject DN is empty, the subjectAltName should be
> marked as critical.  IIRC some Java implementations reject the certificate
> otherwise.

I have just created a client cert with empty subjectName and critical
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier
non-critical SAN cert.  See below for the output of the cert.

>> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.
> OpenSSL supports empty (empty RDN sequence) subject DNs.
> The "-subj /" option is one way to make that happen.
>
> Empty is of course different from "absent", which is not
> possible, since the subject DN is a required component of
> an X.509 certificate.

I now have it clear that Empty SN is NOT a cert with NO SN.  It is there
with null content.

Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             c9:8f:b2:7b:e1:95:74:d0
         Signature Algorithm: ED25519
         Issuer: CN = 2001:24:28:14::/64
         Validity
             Not Before: Aug 16 14:54:58 2019 GMT
             Not After : Aug 25 14:54:58 2020 GMT
         Subject:
         Subject Public Key Info:
             Public Key Algorithm: ED25519
                 ED25519 Public-Key:
                 pub:
                     69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
                     c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
                     4c:a5
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Cert Type:
                 SSL Client, S/MIME
             Netscape Comment:
                 OpenSSL Generated Client Certificate
             X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
             X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

             X509v3 Key Usage: critical
                 Digital Signature, Non Repudiation, Key Encipherment
             X509v3 Extended Key Usage:
                 TLS Web Client Authentication, E-mail Protection
             X509v3 Subject Alternative Name: critical
                 IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
     Signature Algorithm: ED25519
          01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
          4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
          dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
          ba:1a:b4:17:c0:bb:0f:da:be:02


Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

OpenSSL - User mailing list
Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default).

If size is a hard constraint:
 - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 octets). Depending on your use-case, you may need to tweak the EKU (or remove it completely).
 - SKI and AKI extensions may not be necessary
 - Key Usage may be marked as non critical (it's a SHOULD in PKIX)

A quick reading of RFC8002 tells me that you may need to include the IssuerAltName extension as well?

Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » <[hidden email] au nom de [hidden email]> a écrit :

    Viktor,
   
   
    On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
    >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users <[hidden email]> wrote:
    >>
    >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"
    > This is wrong.  When the subject DN is empty, the subjectAltName should be
    > marked as critical.  IIRC some Java implementations reject the certificate
    > otherwise.
   
    I have just created a client cert with empty subjectName and critical
    subjectAltName.  Interestingly, it is 4 bytes larger than the earlier
    non-critical SAN cert.  See below for the output of the cert.
   
    >> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.
    > OpenSSL supports empty (empty RDN sequence) subject DNs.
    > The "-subj /" option is one way to make that happen.
    >
    > Empty is of course different from "absent", which is not
    > possible, since the subject DN is a required component of
    > an X.509 certificate.
   
    I now have it clear that Empty SN is NOT a cert with NO SN.  It is there
    with null content.
   
    Thank you all.
   
    $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
    Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
                 c9:8f:b2:7b:e1:95:74:d0
             Signature Algorithm: ED25519
             Issuer: CN = 2001:24:28:14::/64
             Validity
                 Not Before: Aug 16 14:54:58 2019 GMT
                 Not After : Aug 25 14:54:58 2020 GMT
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
                         69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
                         c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
                         4c:a5
             X509v3 extensions:
                 X509v3 Basic Constraints:
                     CA:FALSE
                 Netscape Cert Type:
                     SSL Client, S/MIME
                 Netscape Comment:
                     OpenSSL Generated Client Certificate
                 X509v3 Subject Key Identifier:
    8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
                 X509v3 Authority Key Identifier:
    keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA
   
                 X509v3 Key Usage: critical
                     Digital Signature, Non Repudiation, Key Encipherment
                 X509v3 Extended Key Usage:
                     TLS Web Client Authentication, E-mail Protection
                 X509v3 Subject Alternative Name: critical
                     IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
         Signature Algorithm: ED25519
              01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
              4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
              dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
              ba:1a:b4:17:c0:bb:0f:da:be:02
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

Robert Moskowitz


On 8/16/19 12:34 PM, Erwann Abalea wrote:

> Bonjour,
>
> Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size.
>
> Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default).
>
> If size is a hard constraint:
>   - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 octets). Depending on your use-case, you may need to tweak the EKU (or remove it completely).
>   - SKI and AKI extensions may not be necessary
>   - Key Usage may be marked as non critical (it's a SHOULD in PKIX)

I will look at this and figure out what to change in my .cnf.  I have
been using what I have in my:

draft-moskowitz-eddsa-pki

> A quick reading of RFC8002 tells me that you may need to include the IssuerAltName extension as well?

That is the 8002 SHOULD.  But following rfc 2119 on SHOULD, since I can
calculate the Issuer HHIT from the prefix in issuerName and the Issuer's
Public Key (not carried in the client cert, got to go up the chain to
get that), I am avoiding at this stage of development to closely follow
8002.  Still thinking on all this.

Thank you on your help

>
> Cordialement,
> Erwann Abalea
>
> Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » <[hidden email] au nom de [hidden email]> a écrit :
>
>      Viktor,
>      
>      
>      On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
>      >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users <[hidden email]> wrote:
>      >>
>      >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical"
>      > This is wrong.  When the subject DN is empty, the subjectAltName should be
>      > marked as critical.  IIRC some Java implementations reject the certificate
>      > otherwise.
>      
>      I have just created a client cert with empty subjectName and critical
>      subjectAltName.  Interestingly, it is 4 bytes larger than the earlier
>      non-critical SAN cert.  See below for the output of the cert.
>      
>      >> I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, with no relative disintuished name components, is not the same as not present.
>      > OpenSSL supports empty (empty RDN sequence) subject DNs.
>      > The "-subj /" option is one way to make that happen.
>      >
>      > Empty is of course different from "absent", which is not
>      > possible, since the subject DN is a required component of
>      > an X.509 certificate.
>      
>      I now have it clear that Empty SN is NOT a cert with NO SN.  It is there
>      with null content.
>      
>      Thank you all.
>      
>      $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
>      Certificate:
>           Data:
>               Version: 3 (0x2)
>               Serial Number:
>                   c9:8f:b2:7b:e1:95:74:d0
>               Signature Algorithm: ED25519
>               Issuer: CN = 2001:24:28:14::/64
>               Validity
>                   Not Before: Aug 16 14:54:58 2019 GMT
>                   Not After : Aug 25 14:54:58 2020 GMT
>               Subject:
>               Subject Public Key Info:
>                   Public Key Algorithm: ED25519
>                       ED25519 Public-Key:
>                       pub:
>                           69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
>                           c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
>                           4c:a5
>               X509v3 extensions:
>                   X509v3 Basic Constraints:
>                       CA:FALSE
>                   Netscape Cert Type:
>                       SSL Client, S/MIME
>                   Netscape Comment:
>                       OpenSSL Generated Client Certificate
>                   X509v3 Subject Key Identifier:
>      8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
>                   X509v3 Authority Key Identifier:
>      keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA
>      
>                   X509v3 Key Usage: critical
>                       Digital Signature, Non Repudiation, Key Encipherment
>                   X509v3 Extended Key Usage:
>                       TLS Web Client Authentication, E-mail Protection
>                   X509v3 Subject Alternative Name: critical
>                       IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
>           Signature Algorithm: ED25519
>                01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
>                4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
>                dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
>                ba:1a:b4:17:c0:bb:0f:da:be:02
>      
>      
>      
>

Reply | Threaded
Open this post in threaded view
|

Re: client certs with no subjectName only SAN

JordanBrown
In reply to this post by OpenSSL - User mailing list
On 8/16/2019 9:34 AM, Erwann Abalea via openssl-users wrote:
Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default).


Is there a preferred alternative to the "Netscape Comment"?  That seems like a useful attribute, and I don't find anything more generic.
-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris