Re: client certs with no subjectName only SAN
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
Re: client certs with no subjectName only SAN
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 » 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 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
Re: client certs with no subjectName only SAN
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 » 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 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
Re: client certs with no subjectName only SAN
Viktor, On 8/16/19 8:41 AM, Viktor Dukhovni wrote: On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 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
Re: client certs with no subjectName only SAN
> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users > 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.
Re: client certs with no subjectName only SAN
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.
Re: client certs with no subjectName only SAN
>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 :)
Re: client certs with no subjectName only SAN
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 » 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.
Re: client certs with no subjectName only SAN
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
Re: client certs with no subjectName only SAN
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.
Re: Client certs
On Sat, Nov 15, 2003 at 06:40:26PM -0500, David wrote: > What kind of voodoo is required to get a client to send a cert? > > Both client and server are calling SSL_CTX_use_certificate_file() and > SSL_CTX_use_PrivateKey_file(), and the server is calling > SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL). > > Despite this, SSL_get_peer_certificate (*ssl) returns a cert on the > client but the server dies, spitting out: > 7532:error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no > certificate returned:s3_srvr.c:1988: > > It looks like both certs are actually being passed, based on a network > trace. > > What am I missing? Maybe the server to send list of acceptable SSL client CA certificates SSL_CTX_set_client_CA_list() > I'm using RH9's stock libraries (0.9.7a), and working with the demo/ssl > code in the openssl source package from openssl.org. -- Naina library: http://www.unity.net/~vf/naina_r1.tgz __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Client certs
Check these pages: http://www.mysql.com/doc/en/Secure_basics.html http://www.mysql.com/doc/en/Secure_Create_Certs.html http://www.mysql.com/doc/en/Secure_GRANT.html You need to have a certificate for the server and the client signed by the same CA. Hope this helps Bart... -Original Message- From: theoharis tsenis [mailto:[EMAIL PROTECTED] Sent: 22 July 2003 21:26 To: [EMAIL PROTECTED] Subject: Client certs Hi, i am trying to use openssl under mysql. I finally compile everything and they looks ok. At the PC of the mysql-server i create a signed-certificate for the server and a signed-certificate for a client. When i connect to the mysql from the console of the PC everything works fine. But when i connect to the mysql from a remote client there are some questions (newbie in the openssl). Fist what certificates to use to the remote clients, secondly the creation of these certificates must be done at the remote clients seperately or just copy-paste the certs, thirdly the mysql-server need to have stored locally remote clients certs? Please advice or redirect me? Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
