On Saturday 06 December 2008 06:33:13 Frank Hecker wrote:
> * SECOM Trust doesn't currently support OCSP. OCSP is not (yet)
> mandatory for EV, so this is not an issue from a policy perspective.
> IIRC this will not pose a technical problem either, as long as EV certs
> issued by SECOM Trust don't
I have created a X.509 v3 client certificate using OpenSSL.
The CN and OU field contain UTF8 characters, in this case Thai
characters for testing purposes.
When I import this certificate into the Windows certificate store it
shows all fields correctly, ie I can actually see the Thai character
Nelson B Bolyard wrote:
(Snipped. Your interpretation is not inaccurate but isn't where we are
heading.)
I think this list is NOT the place for the debate over the superiority
of open vs. closed source software. This is the open source locker room,
not the open/closed source battle field.
Given this example, and using traditional technologies and
protocols, this problem appears intractable. However, there
is a new solution - becoming an OASIS standard shortly - that
not only solves this problem, but goes beyond this stage of
the problem to address the next stage of the problem.
E
On 12/03/2008 07:09 PM, Nelson B Bolyard:
Kaspar Brand wrote, On 2008-12-03 08:36 PST:
http://sni.velox.ch/httpd-2.2.x-sni.patch is working pretty well for
2.2, though (have a look at https://sni.velox.ch).
Kaspar, Thank you for building and maintaining that web site.
It is the ONLY web site
Paul Hoffman wrote:
>> I have created a X.509 v3 client certificate using OpenSSL.
>>
>> The CN and OU field contain UTF8 characters, in this case Thai
>> characters for testing purposes.
>
> Are those fields encoded with UTF8String as they should be?
Exactly, that's the crucial question. Chanc
6 matches
Mail list logo