Issue #12501 has been updated by Jascha Lee.
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?
bob2 : unclear what you mean
dpittman : jaschal: is that an authenticated or unauthenticated request?
bob2 : do you mean "I allowed the IP address that the master sees but it
doesn't accept the cert request"?
dpittman : jaschal: For authenticated requests - everything except the
initial CSR submission, pretty much - we use the *certname*
[01:18a] jaschal : Yeah, I think it is a VPN.
[01:18a] 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
[01:18a] jaschal: that IP address is the NAT IP. Why does it care about
that?
[01:19a] dpittman : jaschal: Ah, so that is an authenticated request. We
use the CN out of the certificate there, not anything around DNS.
[01:19a] bob2 : does the master allow that address?
[01:19a] dpittman : jaschal: ...can you paste your auth.conf file somewhere
for us? Something very odd is happening there.
[01:19a] jaschal :
path ~ ^/catalog/([^/]+)$
method find
allow $1
[01:20a] dpittman : jaschal: The certificate and the part should match, so
... yeah. Should work.
[01:20a] 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.
[01:20a] dpittman : jaschal: 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.
[01:20a] jaschal : ah, ok
[01:21a] jaschal: I'm stuck
jaschal : (do you want the rest of the auth.conf file? This is the line
where it's stopping)
[01:22a] dpittman : jaschal: No, assuming you don't have anything else that
would match that request, that should allow it.
[01:23a] jaschal : We are not using puppet generated certs, but our own.
Have you heard anything about Subject: line ordering causing problems?
[01:23a] dpittman : jaschal: I was going to ask about that, because I can't
recall what ours looks like...
[01:24a] jaschal : yeah, good ones are: C ST L O OU CN
[01:24a] jaschal: but bad one's we have are: CN O OU L ST C
[01:24a] dpittman : jaschal: So, we generate our own with the subject
`CN=${certname}` and nothing more.
[01:24a] dpittman: jaschal: I don't /think/ we do anything to split those
down, .......
[01:24a] jaschal : Do I need to clean out anything from the master, if a
client tried to connect with a different cert?
[01:25a] dpittman : jaschal: 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,
[01:25a] dpittman : jaschal: Let me dig a little longer into this code.
[01:25a] jaschal : okay, I'll let you
[01:27a] nevyn : • nevyn suspects this is 4yearold code that has justworked
till now
[01:27a] dpittman : jaschal: what are you running your master under,
please? Apache/Passenger, or something else?
[01:28a] jaschal : dpittman: passenger
[01:28a] jaschal : someone who knows more about this than me, suggested
this change:
[01:28a] dpittman : jaschal: awesome. here is the bug: dn_matchdata =
dn.match(/^.*?CN\s*=\s*(.*)/)
[01:28a] jaschal :
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e -> RequestHeader set
X-SSL-Subject %{SSL_CLIENT_S_DN_CN}e
[01:28a] dpittman : jaschal: 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.
[01:28a] jaschal : and RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e ->
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN_CN}e
[01:29a] jaschal: a ha!
[01:29a] dpittman : jaschal: So, with the "good" ones we think certname ==
CN, with the bad ones, certname == "cn_value.example.com/ST=eueueu/..."
[01:29a] jaschal : so order *does* matter
[01:29a] dpittman : jaschal: yes. It *shouldn't* matter, but it does.
[01:30a] dpittman: jaschal: 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.
[01:30a] 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.
[01:30a] dpittman : jaschal: You could just copy and paste the IRC log in,
if you want.
[01:30a] dpittman: jaschal: ...so, yeah. The work-around is make the CN
the last component. That will work.
----------------------------------------
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.
