Skip Menu |

This queue is for tickets about the Net-SSLGlue CPAN distribution.

Report information
The Basics
Id: 57354
Status: resolved
Priority: 0/
Queue: Net-SSLGlue

People
Owner: Nobody in particular
Requestors: PMOONEY [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 0.2
Fixed in: (no value)



Subject: SSL_verifycn_scheme and wildcards
I do not think this is a bug, more something that could be documented (or set a sensible default?). The CN in the certificate was *.givex.com. The certificate was rejected as I was talking to dev.givex.com because it was not an exact match. To make sure this matched (because a wildcard is present) I needed to do the following: use Net::SSLGlue::LWP; use XML::Compile::WSDL11; use XML::Compile::SOAP11; use XML::Compile::Transport::SOAPHTTP; # code code code { local $Net::SSLGlue::LWP::SSLopts{SSL_ca_file} = $self->_config->{ssl}->{root_ca_file}; $Net::SSLGlue::LWP::SSLopts{SSL_verifycn_scheme} = { wildcards_in_cn => 'anywhere', check_cn => 'when_only' } # code code code };
| I do not think this is a bug, more something that could be documented | (or set a sensible default?). | | The CN in the certificate was *.givex.com. The certificate was rejected | as I was talking to dev.givex.com because it was not an exact match. | To make sure this matched (because a wildcard is present) I needed to do | the following: It's neither a bug nor a bad default. The RFC for http (RFC 2818) states clearly that a wildcard can only be in the subjectAltName, but not in the CN. This is the same for ldap (RFC 4513), POP3, IMAP, ACAP (RFC 2995) and NNTP (RFC 4642). So if your certificate has a wildcard in the CN it is probably against most of these RFCs. If SOAP is different please point me to the appropriate RFC.