On 20.12.2010 22:28, Stefan Fritsch wrote:
> The problem is that ssl_var_lookup can be called for an open
> connection before the request_rec is created. In the current trunk,
> this does not seem to be done for the SSL_*_DN variables, but it is
> done for other variables like SSL_CLIENT_S_DN_CN
On Monday 20 December 2010, Kaspar Brand wrote:
> > Instead of an SSLOption (which would require a request_rec to
> > lookup), I have implemented a per-vhost option for restoring
> > compatibility.
>
> Could we pass the request_rec from ssl_var_lookup() to
> ssl_var_lookup_ssl(), and from there o
On 19.12.2010 01:58, Stefan Fritsch wrote:
> emailaddress=test-...@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San
> Francisco,ST=California,C=US
>
> Is this what we want? We could use XN_FLAG_DN_REV to keep the old
> order. I haven't tried UTF8 characters, yet.
Thanks, Stefan, for working on
On Sunday 19 December 2010, Dr Stephen Henson wrote:
> On 29/11/2010 19:34, Dr Stephen Henson wrote:
> > You can get a UTF8String from most string types using
> > ASN1_STRING_to_UTF8(). This should be adequate for most
> > purposes: it doesn't handle the more bizarre TeletexString shift
> > convers
On 29/11/2010 19:34, Dr Stephen Henson wrote:
>
> You can get a UTF8String from most string types using ASN1_STRING_to_UTF8().
> This should be adequate for most purposes: it doesn't handle the more bizarre
> TeletexString shift conversions but those are rarely encountered in practice.
>
I shoul
On Monday 29 November 2010, Dr Stephen Henson wrote:
> On 24/11/2010 07:07, Kaspar Brand wrote:
> > On 20.11.2010 20:24, Stefan Fritsch wrote:
> >> On Fri, 19 Nov 2010, Joe Orton wrote:
> >>> We could support this better by having a new set of exports:
> >>> SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)
On 24/11/2010 07:07, Kaspar Brand wrote:
> On 20.11.2010 20:24, Stefan Fritsch wrote:
>> On Fri, 19 Nov 2010, Joe Orton wrote:
>>> We could support this better by having a new set of exports:
>>>
>>> SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
>>>
>>> (or something similarly named)
>>>
>>> which work
On 20.11.2010 20:24, Stefan Fritsch wrote:
> On Fri, 19 Nov 2010, Joe Orton wrote:
>> We could support this better by having a new set of exports:
>>
>> SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
>>
>> (or something similarly named)
>>
>> which works the same as _DN_ but exports the attributes as a
On Fri, 19 Nov 2010, Joe Orton wrote:
On Fri, Nov 19, 2010 at 07:13:01AM +0100, Kaspar Brand wrote:
On 17.11.2010 15:53, Igor Galić wrote:
it might be appropriate to ping dev@ with this problem
I'm not sure if it's a bug or a feature.
I'd call it a missing feature... the problem is that mod_
On Fri, Nov 19, 2010 at 07:13:01AM +0100, Kaspar Brand wrote:
> On 17.11.2010 15:53, Igor Galić wrote:
> > it might be appropriate to ping dev@ with this problem
> > I'm not sure if it's a bug or a feature.
>
> I'd call it a missing feature... the problem is that mod_ssl treats all
> values of any
On 17.11.2010 15:53, Igor Galić wrote:
> it might be appropriate to ping dev@ with this problem
> I'm not sure if it's a bug or a feature.
I'd call it a missing feature... the problem is that mod_ssl treats all
values of any DN attribute (subject or issuer) as a sequence of 8-bit
characters.
> --
Hi Myles,
it might be appropriate to ping dev@ with this problem
I'm not sure if it's a bug or a feature.
So long,
i
- "Myles Bunbury (Myles)" wrote:
> > Which version of OpenSSL do you have?
>
> openssl-0.9.8e-12.el5_4.6
> xmlsec1-openssl-1.2.9-8.1.1
>
> > What locale is your system
12 matches
Mail list logo
