On Sun, Aug 02, 2015 at 09:33:48AM +0200, Kaspar Brand wrote:
> On 19.07.2015 17:24, Kaspar Brand wrote:
> > But, to be on the safe side, I think we could a) move the OBJ_create()
> > call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
>
> For the record: I have now committed thi
On Sun, Aug 02, 2015 at 09:33:48AM +0200, Kaspar Brand wrote:
> On 19.07.2015 17:24, Kaspar Brand wrote:
> > But, to be on the safe side, I think we could a) move the OBJ_create()
> > call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
>
> For the record: I have now committed thi
On 19.07.2015 17:24, Kaspar Brand wrote:
> But, to be on the safe side, I think we could a) move the OBJ_create()
> call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
For the record: I have now committed this to trunk with r1693792.
Kaspar
On 13.07.2015 16:03, Joe Orton wrote:
> On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
>> @@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
>>
>> free_dh_params();
>>
>> +OBJ_cleanup();
>> +
>> return APR_SUCCESS;
>
> From being burnt previously th
On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
> @@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
>
> free_dh_params();
>
> +OBJ_cleanup();
> +
> return APR_SUCCESS;
>From being burnt previously three or four times, I get scared by OpenSSL
proces
On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
> On 29.06.2015 15:14, Jan Pazdziora wrote:
> > How about just passing char * and doing all the mapping logic
> > including possible OBJ_create in parse_otherName_value? My goal here
> > is to have all the "hard" work of determining the
On 29.06.2015 15:14, Jan Pazdziora wrote:
> How about just passing char * and doing all the mapping logic
> including possible OBJ_create in parse_otherName_value? My goal here
> is to have all the "hard" work of determining the semantics isolated
> in one place.
>
> Please see patch attached.
Yo
On 06/29/2015 03:14 PM, Jan Pazdziora wrote:
On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote:
On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
On 22.06.2015 10:37, Jan Pazdziora wrote:
Please find a new patch attached which I hope covers all the
parts you've outlined
On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote:
> On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
> > On 22.06.2015 10:37, Jan Pazdziora wrote:
> > > Please find a new patch attached which I hope covers all the
> > > parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN
On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
> On 22.06.2015 10:37, Jan Pazdziora wrote:
> > Please find a new patch attached which I hope covers all the
> > parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
>
> Thanks. Your implementation assumes that only a single otherNa
On 22.06.2015 10:37, Jan Pazdziora wrote:
> Please find a new patch attached which I hope covers all the
> parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
Thanks. Your implementation assumes that only a single otherName form
(msUPN) needs to be supported, but I would prefer to code it in
On Sun, Jun 21, 2015 at 08:55:02AM +0200, Kaspar Brand wrote:
>
> The point with the otherName SAN type is that it's yet another bag of
> potentially arbitrary ASN.1 stuff, actually (not just simple strings, as
> is the case for rfc822Name or dNSName):
>
>GeneralName ::= CHOICE {
> ot
On 19.06.2015 16:51, Jan Pazdziora wrote:
> On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
>> I think a more generic way would to have something like
>> SSL_CLIENT_OID__n, so that we wouldn't have to add a new field
>> each time.
>> In this case, that would be: SSL_CLIENT_OID_1.3.6.1.
On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
> >
> > I'd appreciate any comments about suitability of such change, as well
> > as the implementation. Specifically, I'm not sure if people will
> > prefer the generic and curren
On Fri, Jun 19, 2015 at 11:56 AM, Yann Ylavic wrote:
>
> Instead of SSL_CLIENT_OID_, we could also have something like
> SSL_CLIENTn since the underlying mod_ssl
> code handles both (IIRC).
> I don't know if SAN_otherName/UPN have a short/long name though, but many
> have.
Nope, SAN as an oi
On Fri, Jun 19, 2015 at 11:32 AM, Jan Kaluža wrote:
> On 06/18/2015 12:22 PM, Yann Ylavic wrote:
>>
>> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora
>> wrote:
>>>
>>>
>>> I'd appreciate any comments about suitability of such change, as well
>>> as the implementation. Specifically, I'm not sure
On 06/18/2015 12:22 PM, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
I'd appreciate any comments about suitability of such change, as well
as the implementation. Specifically, I'm not sure if people will
prefer the generic and currently proposed
SSL_CLIEN
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
>
> I'd appreciate any comments about suitability of such change, as well
> as the implementation. Specifically, I'm not sure if people will
> prefer the generic and currently proposed
>
> SSL_CLIENT_SAN_otherName_n
>
> which gets any
Hello,
I've noticed that support for getting subjectAltName entries Email and
Type landed in 2.4.13, via r1676087.
We've come across another type in subjectAltName, Microsoft Universal
Principal Name (OID 1.3.6.1.4.1.311.20.2.3) which would be useful to
retrieve from the certificate and use for
19 matches
Mail list logo
