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 this to
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 this to
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 three or four
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 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
process
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.
You're
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
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 otherName
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 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 a
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 {
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_oid_n, so that we wouldn't have to add a new field
each time.
In this case, that would be:
On 06/18/2015 12:22 PM, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora jpazdzi...@redhat.com 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
On Fri, Jun 19, 2015 at 11:56 AM, Yann Ylavic ylavic@gmail.com wrote:
Instead of SSL_CLIENT_OID_, we could also have something like
SSL_CLIENT__oid|shortname|fullname__n since the underlying mod_ssl
code handles both (IIRC).
I don't know if SAN_otherName/UPN have a short/long name though,
On Fri, Jun 19, 2015 at 11:32 AM, Jan Kaluža jkal...@redhat.com wrote:
On 06/18/2015 12:22 PM, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora jpazdzi...@redhat.com
wrote:
I'd appreciate any comments about suitability of such change, as well
as the implementation.
On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora jpazdzi...@redhat.com 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
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora jpazdzi...@redhat.com 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
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
