Issue #12501 has been updated by Daniel Pittman.
Category set to network
Status changed from Unreviewed to Accepted
>From IRC, where this was discussed:
<pre>
jaschal: Hello oh wise pullers of strings, I have a question about resolving
nat'd hosts. Specifically: how do I properly get past auth.conf thinking the
client is not itself, but its NAT'd IP and Forbidding the request?
dpittman: is that an authenticated or unauthenticated request?
jaschal: I would use VPNs for that kind of thing
dpittman: For authenticated requests - everything except the initial CSR
submission, pretty much - we use the *certname*
jaschal: Yeah, I think it is a VPN.
jaschal: err: Could not retrieve catalog from remote server: Error 403 on
SERVER: Forbidden request: systpx00.tivo.com/O=TiVo
Inc./OU=IT/L=Alviso/ST=California/C=US(192.168.140.34) access to
/catalog/systpx00.tivo.com [find] authenticated at line 52
jaschal: that IP address is the NAT IP. Why does it care about that?
dpittman: Ah, so that is an authenticated request. We use the CN out of the
certificate there, not anything around DNS.
dpittman: ...can you paste your auth.conf file somewhere for us? Something
very odd is happening there.
jaschal: path ~ ^/catalog/([^/]+)$
jaschal: method find
jaschal: allow $1
dpittman: The certificate and the part should match, so ... yeah. Should work.
:/
jaschal: There was an issue where the cert's subject line was in a different
order (CN was listed first), I thought that might be causing problems.
dpittman: it reports the IP address because it never hurts to know where that
request came from, even if that isn't part of how we make the auth decision.
jaschal: ah, ok
jaschal: I'm stuck
jaschal: (do you want the rest of the auth.conf file? This is the line where
it's stopping)
dpittman: No, assuming you don't have anything else that would match that
request, that should allow it. :(
jaschal: We are not using puppet generated certs, but our own. Have you heard
anything about Subject: line ordering causing problems/
dpittman: I was going to ask about that, because I can't recall what ours looks
like...
jaschal: yeah, good ones are: C ST L O OU CN
jaschal: but bad one's we have are: CN O OU L ST c
dpittman: So, we generate our own with the subject `CN=${certname}` and nothing
more.
dpittman: I don't /think/ we do anything to split those down, .......
jaschal: Do I need to clean out anything from the master, if a client tried to
connect with a different cert?
dpittman: Oh, my. I suspect that our auth code is buggy, and your certs just
happened to work for it until now. Oh, my, my, my,
dpittman: Let me dig a little longer into this code. :)
jaschal: okay, I'll let you ;)
dpittman: what are you running your master under, please? Apache/Passenger, or
something else?
jaschal: passenger
jaschal: someone who knows more about this than me, suggested this change:
dpittman: awesome. here is the bug: dn_matchdata =
dn.match(/^.*?CN\s*=\s*(.*)/)
jaschal: RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e -> RequestHeader
set X-SSL-Subject %{SSL_CLIENT_S_DN_CN}e
dpittman: See how that has an *unterminated* match after the CN? If your CN is
the last component it works, but if you have something else after CN it gets
included.
jaschal: and RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
jaschal: -> RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN_CN}e
jaschal: a ha!
dpittman: So, with the "good" ones we think certname == CN, with the bad ones,
certname == "cn_value.example.com/ST=eueueu/..."
jaschal: so order *does* matter
dpittman: yes. It *shouldn't* matter, but it does.
dpittman: could you file a ticket for us with those details in? That way if
someone else fields it and needs to talk to you they can.
jaschal: Yeah, I think we thought that, but…. I regen'd the cert, and am
*still* seeing the problem. So there must be something else going on too/else,
etc.
dpittman: You could just copy and paste the IRC log in, if you want. :)
dpittman: ...so, yeah. The work-around is make the CN the last component.
That will work.
jaschal: will file
dpittman: We will totally fix that for you, so that things work properly in
future. Thanks for actually calling that out.
jaschal: thanks! btw I'm running 2.6.6
</pre>
----------------------------------------
Bug #12501: Certificate CN parsing is broken
https://projects.puppetlabs.com/issues/12501
Author: Jascha Lee
Status: Accepted
Priority: Normal
Assignee:
Category: network
Target version:
Affected Puppet version: 2.6.6
Keywords:
Branch:
In lib/puppet/network/http/rack/rest.rb, the regex to extract the Common Name
(CN) from a cert has an unterminated pattern that will only work if the CN
comes last in the Subject: line. If it doesn't come last, the pattern will
also match everything after it causing the client to not be authenticated:
dn_matchdata = dn.match(/^.*?CN\s*=\s*(.*)/)
err: Could not retrieve catalog from remote server: Error 403 on SERVER:
Forbidden request: hostname.tivo.com/O=TiVo
Inc./OU=IT/L=Alviso/ST=California/C=US(x.x.x.x) access to
/catalog/hostname.tivo.com [find] authenticated at line 52
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
