Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, 2010-06-03 at 21:35 -0400, Victor Duchovni wrote: The problem is that only the application knows which names are those of the peer it tried to reach. True, but the app could easily provide that information to a library function. If you look at the 250 lines of code I referenced, almost none of that is actually app-specific. My code could be abstracted to take the app-specific information as arguments without too much pain. -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Mon, Jun 07, 2010 at 03:03:28PM +0100, David Woodhouse wrote: On Thu, 2010-06-03 at 21:35 -0400, Victor Duchovni wrote: The problem is that only the application knows which names are those of the peer it tried to reach. True, but the app could easily provide that information to a library function. Not quite that simple, as in the case of Postfix, for example, the application supports a list of acceptable names, some of which can be sub-domain wild-cards. An API to iterate over the subjectAltName DNS names (validated to not contain embedded NULs, ...) if present or else the CN (normalized to UTF-8 and validated to no contain embedded NULs, ...) would be of general use. If you look at the 250 lines of code I referenced, almost none of that is actually app-specific. My code could be abstracted to take the app-specific information as arguments without too much pain. Different apps have somewhat different name matching policies, but I would agree that *robust* name *extraction*, should and could be easier. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Sat, Jun 05, 2010, jeff wrote: I did a little debugging and managed to fix on my end. The issue is now resolved. There's nothing wrong with OpenSSL1.0.0's handling of nameConstraints. It just Rocks! Thank you for the update. When I wrote it it was checked against the RFC3280 compliance test but it's nice to know it works in a real world test too. I did need to check the exact meaning in the mailing lists as the RFC wasn't clear to me. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
I tested this openssl 1.0.0. Error 34 is gone now but now error 47 shows up which shows the name constraint is being applied. However, it's being applied or verified in a way that I don't understand. To show you I have simplified the test. Generating only one end certificate and specifying one very simple name constraint. The name constraint is chosen in a way to eliminate an guess work and unspecified matching requirements. Here are some relevant output. The test scripts are attached. Command output: $ ./testnameconst.sh 2/dev/null OpenSSL 1.0.0a 1 Jun 2010 error 47 at 0 depth lookup:permitted subtree violation ERROR: Good cert should have been verified but it didn't End entity (Good) cert: Version: 3 (0x2) Serial Number: 17 (0x11) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, CN=SUB CA Subject: O=good, CN=Good X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication subCA cert: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Root CA, C=US Validity Not Before: Jun 5 03:10:07 2010 GMT Not After : Jun 5 03:10:07 2011 GMT Subject: C=US, ST=NY, O=SubCa, CN=SubCA X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Name Constraints: critical Permitted: DirName: CN = Good, O = good This email contains Morega Systems Inc. Privileged and Confidential information.# OpenSSL configuration file for NameConstraint Test # HOME= . RANDFILE= $ENV::HOME/.rnd [ ca ] default_ca = CA_default [ CA_default ] dir = . new_certs_dir = $dir/ crl_dir = $dir/ database= $dir/index certificate = $dir/rootcacert.pem serial = $dir/serial private_key = $dir/rootcakey.pem RANDFILE= $dir/.rand x509_extensions = cert_ext unique_subject = no name_opt= ca_default cert_opt= ca_default default_crl_days= 30 default_days= 365 default_md = sha1 preserve= no policy = policy_default email_in_dn = no msie_hack = no copy_extensions = none [ policy_default ] countryName = optional stateOrProvinceName = optional organizationName= optional organizationalUnitName = optional commonName = supplied emailAddress= optional [ req ] default_bits= 1024 default_keyfile = ./rootcakey.pem default_md = sha1 prompt = no distinguished_name = root_ca_distinguished_name string_mask = nombstr [ root_ca_distinguished_name ] commonName = Root CA countryName = US [ cert_ext ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always basicConstraints = critical,CA:FALSE keyUsage = critical, keyCertSign, cRLSign extendedKeyUsage=clientAuth [ root_ca_ext ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always keyUsage = critical, keyCertSign, cRLSign basicConstraints = critical,CA:TRUE [ trusted_ca_ext ] # Extensions for the Sub CA subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always keyUsage = critical, keyCertSign, cRLSign basicConstraints = critical,CA:TRUE,pathlen:0 nameConstraints = critical,@name_const_section [ name_const_section ] #excluded;dirName=excluded_trust_ca_DN permitted;dirName=permitted_trust_ca_DN [ excluded_trust_ca_DN ] O=bad [ permitted_trust_ca_DN ] CN=Good O=good # OpenSSL configuration file for NameConstraint Test # HOME= . RANDFILE= $ENV::HOME/.rnd [ ca ] default_ca = SUBCA_default [ SUBCA_default ] dir = . new_certs_dir = $dir/ crl_dir = $dir/ database= $dir/subcaindex certificate = $dir/subcacert.pem serial = $dir/subcaserial private_key = $dir/subcakey.pem RANDFILE= $dir/.rand x509_extensions = cert_ext unique_subject = no name_opt= ca_default cert_opt= ca_default default_crl_days= 30 default_days= 365 default_md = sha1 preserve= no policy = policy_default email_in_dn = no msie_hack = no copy_extensions = none [ policy_default ] countryName = optional stateOrProvinceName = optional organizationName= optional organizationalUnitName = optional commonName = supplied emailAddress= optional [ req ] default_bits= 1024 default_keyfile = ./subcakey.pem default_md = sha1 prompt
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
I did a little debugging and managed to fix on my end.
The issue is now resolved. There's nothing wrong with OpenSSL1.0.0's
handling of nameConstraints. It just Rocks!
For those who might run into the same problem i'll explain more.
Debugging revealed the problem to be in the following area:
Breakpoint 2, nc_dn (nm=0x8269a98, base=0x8268b38) at
v3_ncons.c:378
378 {
(gdb) p nm-canon_enc
$5 = (unsigned char *) 0x826a590 1\r0\v\006\003U\004\n\f
\004good1\r0\v\006\003U\004\003\f\004good
(gdb) p base-canon_enc
$6 = (unsigned char *) 0x826aab0 1\r0\v\006\003U\004\003\f
\004good1\r0\v\006\003U\004\n\f\004good
(gdb) n
386 if (memcmp(base-canon_enc, nm-canon_enc,
base-canon_enclen))
(gdb) n
387 return X509_V_ERR_PERMITTED_VIOLATION;
(gdb)
The above shows that the provided DN and the allowed one seem out of
order. Look at $5 and $6.
So i took another look at the target cert and the nameConstraint in the
signing cert:
X509v3 Name Constraints: critical
Permitted:
DirName: CN = Good, O = good
Subject: O=good, CN=Good
Look how the order of CN and O are transposed in these entries.
Now whether that is legitimate or not it remains.
Regardless, as soon as I fixed my nameConstraint to:
[ permitted_trust_ca_DN ]
O=good
CN=Good
The problem went away.
I revised my script to have a good test case and a failed one.
The latest are attached for those who may benefit from this.
Thanks to Victor Duchovni and Dr. Stephen Henson for providing guidance and
help.
jeff
On Sat, 2010-06-05 at 20:27 -0400, jeff wrote:
I tested this openssl 1.0.0. Error 34 is gone now but now error 47 shows
up which shows the name constraint is being applied. However, it's being
applied or verified in a way that I don't understand.
To show you I have simplified the test. Generating only one end
certificate and specifying one very simple name constraint.
The name constraint is chosen in a way to eliminate an guess work and
unspecified matching requirements.
Here are some relevant output. The test scripts are attached.
Command output:
$ ./testnameconst.sh 2/dev/null
OpenSSL 1.0.0a 1 Jun 2010
error 47 at 0 depth lookup:permitted subtree violation
ERROR: Good cert should have been verified but it didn't
End entity (Good) cert:
Version: 3 (0x2)
Serial Number: 17 (0x11)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, CN=SUB CA
Subject: O=good, CN=Good
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Client Authentication
subCA cert:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=Root CA, C=US
Validity
Not Before: Jun 5 03:10:07 2010 GMT
Not After : Jun 5 03:10:07 2011 GMT
Subject: C=US, ST=NY, O=SubCa, CN=SubCA
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
d
This email contains Morega Systems Inc. Privileged and Confidential
information.
This email contains Morega Systems Inc. Privileged and Confidential information.# OpenSSL configuration file for NameConstraint Test
#
HOME= .
RANDFILE= $ENV::HOME/.rnd
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = .
new_certs_dir = $dir/
crl_dir = $dir/
database= $dir/index
certificate = $dir/rootcacert.pem
serial = $dir/serial
private_key = $dir/rootcakey.pem
RANDFILE= $dir/.rand
x509_extensions = cert_ext
unique_subject = no
name_opt= ca_default
cert_opt= ca_default
default_crl_days= 30
default_days= 365
default_md = sha1
preserve= no
policy = policy_default
email_in_dn = no
msie_hack = no
copy_extensions = none
[ policy_default ]
countryName = optional
stateOrProvinceName = optional
organizationName= optional
organizationalUnitName = optional
commonName = supplied
emailAddress= optional
[ req ]
default_bits= 1024
default_keyfile = ./rootcakey.pem
default_md = sha1
prompt = no
distinguished_name = root_ca_distinguished_name
string_mask = nombstr
[ root_ca_distinguished_name ]
commonName = Root CA
countryName = US
[ cert_ext ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, Jun 03, 2010, jeff wrote: I will try to include complete attachments with examples. In the mean time I had to say that I was also told (aside from the one of the replies on this thread) that the enforcement of the constraints would be at the time of verification. Therefore I took the following steps to verify the produced certificates. Neither one actually complained at all about the compliance with the constraint. 1. Using openssl verify openssl verify -CAfile trusted.pem -policy_check -x509_strict badcert.pem trusted.pem is a concat of my root CA and the sub-CA certs. Results: badcert.pem: OK Try this instead: openssl verify -CAfile root.pem -untrusted cas.pem badcert.pem Where root.pem contains the root CA only and cas.pem is a concatenation of any intermediate CAs. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On 06/03/2010 06:11 PM, Dr. Stephen Henson wrote: On Thu, Jun 03, 2010, jeff wrote: I have an example, detailed below, that specifies permitted and excluded subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate requests adhering to and violating the name constraints both, even though the nameConstraints are marked as critical. Is this OpenSSL misbehaving or did I miss something when creating the sub-CA certificate or issuing the user certificate? thanks/jeff This would be much easier to test if you'd attached all the relevant certificates and how you are testing them. IMO I do not think that there is any code in openssl that checks during creation whether a new certificate would violate some naming constraints. This is an issue for the registration authority In principle, these are things to be verified by a relying party, and the relying party's trust set containg maybe cross certs with all kinds of restrictions cannot be knwn at that point. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Fri, Jun 04, 2010, Peter Sylvester wrote: On 06/03/2010 06:11 PM, Dr. Stephen Henson wrote: On Thu, Jun 03, 2010, jeff wrote: I have an example, detailed below, that specifies permitted and excluded subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate requests adhering to and violating the name constraints both, even though the nameConstraints are marked as critical. Is this OpenSSL misbehaving or did I miss something when creating the sub-CA certificate or issuing the user certificate? thanks/jeff This would be much easier to test if you'd attached all the relevant certificates and how you are testing them. IMO I do not think that there is any code in openssl that checks during creation whether a new certificate would violate some naming constraints. Yes you are correct. Currently constraints are not checked when a certificate is created using either the 'ca' or 'x509' utilities. It wasn't clear, at least to me, as to whether the report referred to just after creation or during some verification process. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
I tried the following and it created more interesting results. It now fails on the good certificate -- the one that matches the nameConstraint. The error it returns is: error 34 at 1 depth lookup:unhandled critical extension I revised the cnf file to make sure it didn't include the name constraint and ran the test again and it succeeded. I then ran a verify on the Sub-CA certificate itself. Even that fails. This shows that either my forumlation of the constraint is wrong or for some other reason, the name constraint is being applied where it shouldn't. The updated script and config file are enclosed. jeff On Fri, 2010-06-04 at 11:20 +0200, Dr. Stephen Henson wrote: Try this instead: openssl verify -CAfile root.pem -untrusted cas.pem badcert.pem Where root.pem contains the root CA only and cas.pem is a concatenation of any intermediate CAs. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org This email contains Morega Systems Inc. Privileged and Confidential information.# OpenSSL configuration file for NameConstraint Test # HOME= . RANDFILE= $ENV::HOME/.rnd [ ca ] default_ca = CA_default [ CA_default ] dir = . new_certs_dir = $dir/ crl_dir = $dir/ database= $dir/index certificate = $dir/rootcacert.pem serial = $dir/serial private_key = $dir/rootcakey.pem RANDFILE= $dir/.rand x509_extensions = cert_ext unique_subject = no name_opt= ca_default cert_opt= ca_default default_crl_days= 30 default_days= 365 default_md = sha1 preserve= no policy = policy_default email_in_dn = no msie_hack = no copy_extensions = none [ policy_default ] countryName = optional stateOrProvinceName = optional organizationName= optional organizationalUnitName = optional commonName = supplied emailAddress= optional [ req ] default_bits= 1024 default_keyfile = ./rootcakey.pem default_md = sha1 prompt = no distinguished_name = root_ca_distinguished_name string_mask = nombstr [ root_ca_distinguished_name ] commonName = Root CA countryName = US [ cert_ext ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always basicConstraints = critical,CA:FALSE keyUsage = critical, keyCertSign, cRLSign extendedKeyUsage=clientAuth [ root_ca_ext ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always keyUsage = critical, keyCertSign, cRLSign basicConstraints = critical,CA:TRUE [ trusted_ca_ext ] # Extensions for the Sub CA subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always keyUsage = critical, keyCertSign, cRLSign basicConstraints = critical,CA:TRUE,pathlen:0 nameConstraints = critical,@name_const_section [ name_const_section ] excluded;dirName=excluded_trust_ca_DN permitted;dirName=permitted_trust_ca_DN [ excluded_trust_ca_DN ] O=bad [ permitted_trust_ca_DN ] O=good testnameconst.sh Description: application/shellscript
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Fri, Jun 04, 2010 at 01:04:42PM -0400, jeff wrote: I tried the following and it created more interesting results. It now fails on the good certificate -- the one that matches the nameConstraint. The error it returns is: error 34 at 1 depth lookup:unhandled critical extension Did you happen to indicate in any message upthread which version of OpenSSL you are testing with? If so, I am sorry I missed it. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Fri, Jun 04, 2010, jeff wrote: I tried the following and it created more interesting results. It now fails on the good certificate -- the one that matches the nameConstraint. The error it returns is: error 34 at 1 depth lookup:unhandled critical extension Are you using OpenSSL 0.9.8? Name constraints can be created in 0.9.8 but are not processed. You need 1.0.0 to process name constraints. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
yes it's 0.98 I'll do a test with 1.0 before Monday and i'll let everyone know This email contains Morega Systems Inc. Privileged and Confidential information. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Fri, Jun 04, 2010 at 03:50:21PM -0400, jeff wrote: yes it's 0.9.8 I'll do a test with 1.0 before Monday and i'll let everyone know The fact that 0.9.8 does NOT support checking name constraints was mentioned multiple times in this thread. It is not polite to waste list members' time in this way. Please refrain in the future. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
NameConstraints are not being applied (or I don't know how to enforce them?)
I have an example, detailed below, that specifies permitted and excluded subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate requests adhering to and violating the name constraints both, even though the nameConstraints are marked as critical. Is this OpenSSL misbehaving or did I miss something when creating the sub-CA certificate or issuing the user certificate? thanks/jeff openssl.cnf lines for Root CA when issued the sub-CA's certificate: ... nameConstraints = critical,@name_const_section [ name_const_section ] excluded;dirName=excluded_DN permitted;dirName=permitted_DN [ excluded_DN ] O=bad [ permitted_DN ] O=good Print out of the sub-CA's cert (trustedcacert.pem): Certificate Details: Serial Number: 22 (0x16) Validity Not Before: Jun 3 13:13:36 2010 GMT Not After : Jun 3 13:13:36 2011 GMT Subject: countryName = US stateOrProvinceName = NY organizationName = AcmeCorp commonName= AcmeCorp X509v3 extensions: ... X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Name Constraints: critical Permitted: DirName: O = good Excluded: DirName: O = bad Commands issued to create CSRs and sign them with the sub-CA's cert: # signing the good cert req openssl req -new -newkey rsa:2048 -nodes -keyout goodkey.pem \ -sha256 -subj /O=good+CN=Good\/Instance -multivalue-rdn \ goodcsr.pem openssl x509 -CA trustedcacert.pem -CAkey trustedcakey.pem \ -days 365 -req -in goodcsr.pem -set_serial 2 -out goodcert.pem # signing the bad cert req openssl req -new -newkey rsa:2048 -nodes -keyout badkey.pem \ -sha256 -subj /O=bad+CN=Bad\/Instance -multivalue-rdn \ badcsr.pem openssl x509 -CA trustedcacert.pem -CAkey trustedcakey.pem \ -days 365 -req -in badcsr.pem -set_serial 3 -out badcert.pem Print out of the created badcert.pem: Certificate: Data: Version: 1 (0x0) Serial Number: 3 (0x3) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=NY, O=AcmeCorp, CN=AcmeCorp Validity Not Before: Jun 3 13:13:38 2010 GMT Not After : Jun 3 13:13:38 2011 GMT Subject: O=bad, CN=Bad/Instance Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) This email contains Morega Systems Inc. Privileged and Confidential information. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, Jun 03, 2010, jeff wrote: I have an example, detailed below, that specifies permitted and excluded subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate requests adhering to and violating the name constraints both, even though the nameConstraints are marked as critical. Is this OpenSSL misbehaving or did I miss something when creating the sub-CA certificate or issuing the user certificate? thanks/jeff This would be much easier to test if you'd attached all the relevant certificates and how you are testing them. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, Jun 03, 2010 at 09:36:56AM -0400, jeff wrote: I have an example, detailed below, that specifies permitted and excluded subtrees for a sub-CA. Later it uses the sub-CA cert to sign certificate requests adhering to and violating the name constraints both, even though the nameConstraints are marked as critical. I would expect such constraints to only apply when certificates are being *verified*. There seems to be little point in preventing a CA from attempting to sign violating certificates. Generally, OpenSSL does not verify peer names, only the certificate trust chain, and peername checks are left up to applications. Does OpenSSL trust chain validation include any checks on name constraints? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, Jun 03, 2010, Victor Duchovni wrote: Generally, OpenSSL does not verify peer names, only the certificate trust chain, and peername checks are left up to applications. Does OpenSSL trust chain validation include any checks on name constraints? OpenSSL 1.0.0 does, sufficient to cover the PKITS RFC3280 tests. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Thu, 2010-06-03 at 13:47 -0400, Victor Duchovni wrote: Generally, OpenSSL does not verify peer names, only the certificate trust chain, and peername checks are left up to applications. Which is a shame... I'm far too stupid to be writing code like http://git.infradead.org/users/dwmw2/openconnect.git?a=blob;f=ssl.c;hp=v2.25#l436 for myself, and I would much rather have used a library function ;) -- dwmw2 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: NameConstraints are not being applied (or I don't know how to enforce them?)
On Fri, Jun 04, 2010 at 01:19:52AM +0100, David Woodhouse wrote: On Thu, 2010-06-03 at 13:47 -0400, Victor Duchovni wrote: Generally, OpenSSL does not verify peer names, only the certificate trust chain, and peername checks are left up to applications. Which is a shame... I'm far too stupid to be writing code like http://git.infradead.org/users/dwmw2/openconnect.git?a=blob;f=ssl.c;hp=v2.25#l436 for myself, and I would much rather have used a library function ;) The problem is that only the application knows which names are those of the peer it tried to reach. The OpenSSL library is not an HTTPS client, or an SMTP STARTTLS client, ... Which is not too say that peername extraction is made as easy as it could be, but ultimately some of the magic has to happen in application (or application library) code. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
