sun.security.x509.DNSName leading dot in name constraints
Sean Mullan
sean.mullan at oracle.com
Tue Jun 9 12:12:19 UTC 2015
On 06/09/2015 07:21 AM, Sean Mullan wrote:
> -Bcc jdk9-dev
>
> This question is more appropriate for security-dev, so I am copying that
> list for further discussion.
>
> --Sean
>
> On 06/09/2015 02:21 AM, Vyronas Tsingaras wrote:
>> Hi all,
>>
>> I work for the Hellenic Academic and Research Institutions
>> Certification Authority (https://www.harica.gr), a Root Certification
>> Authority included in the NSS, Microsoft and Apple certificate stores.
>> Our RootCA certificate uses the name constraints extension with a
>> small error, instead of just gr, org and edu in the permitted subtrees
>> it has .gr, .edu and .org. As a result certificates issued under our
>> CA fail to verify with Java. We had the same issue with OpenSSL and
>> gnuTLS but fortunately they modified their implementation to
>> accommodate for our situation. I kindly ask if this is something that
>> could also be done with OpenJDK, and if so what would be the best way
>> to implement that. Currently we have a patch against the 'constrains'
>> method of 'DNSName' that just ignores the leading dot in name
>> constraints.
We don't make exceptions for cases like this, as it is not compliant
with RFC 5280. However, are the name constraints only on the root
certificate? When specified this way, they are optional (see RFC 5280
section 6.2). Our implementation does not process them by default (you
must specify them as an optional parameter to the TrustAnchor class).
Are the name constraints included in other certificates chaining back to
the root?
--Sean
>>
>> Kind Regards,
>> Vyronas Tsingaras,
>> Aristotle University of Thessaloniki, IT Center
>>
More information about the security-dev
mailing list