Bug #1525: local host fails to sync with mongrel/apache2 - Any solution?
Sven Mueller
The comment by jamtur01 indicates he believes the problem to be a
configuration problem, and while bureado says that disabling the
SSLCARevocationFile statement in the apache config results in a working
setup (which I wasn't able to verify yet), this information still can't
be found on the "Using Mongrel" page. To repeat the symptoms:
puppetd calls from remote machines to puppetmaster work as expected
(going through apache proxying), but
puppetd calls from the puppetmaster host to itself don't work with one
or more of the following errors:
Could not retrieve catalog: Certificates were not trusted: SSL_connect
returned=1 errno=0 state=SSLv3 read finished A: tlsv1 alert decrypt error
err: /File[/var/lib/puppet/conf/lib]: Failed to generate additional
resources during transaction: Certificates were not trusted: tlsv1 alert
decrypt error
err: /File[/var/lib/puppet/conf/lib]: Failed to retrieve current state
of resource: Certificates were not trusted: tlsv1 alert decrypt error
Could not describe /plugins: Certificates were not trusted: tlsv1 alert
decrypt error
err: Could not retrieve catalog: Certificates were not trusted: tlsv1
alert decrypt error
Are there any solutions allowing the puppet master server to connect to
itself again?
And even if the workaround disabling the CA revocation list actually
works, I would really like to find a solution that keeps the revocation
list checked.
Any ideas?
Regards,
Sven
James Turnbull
Hash: SHA1
Sven Mueller wrote:
> Hi.
>
> The comment by jamtur01 indicates he believes the problem to be a
> configuration problem, and while bureado says that disabling the
> SSLCARevocationFile statement in the apache config results in a working
> setup (which I wasn't able to verify yet), this information still can't
> be found on the "Using Mongrel" page. To repeat the symptoms:
Not verify - does that mean not tested? I would suggest testing the
proposed fix before fishing for other solutions?
Regards
James Turnbull
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJE2fI9hTGvAxC30ARAkM0AJ9Z8vsyK0ZBSFchGW5pztMvdLJmgACgrvwU
pps550gm1w1JoSobFcZmwQE=
=kw5R
-----END PGP SIGNATURE-----
Sven Mueller
> Sven Mueller wrote:
>> The comment by jamtur01 indicates he believes the problem to be a
>> configuration problem, and while bureado says that disabling the
>> SSLCARevocationFile statement in the apache config results in a working
>> setup (which I wasn't able to verify yet), this information still can't
>> be found on the "Using Mongrel" page. To repeat the symptoms:
>
> Not verify - does that mean not tested?
Yes, but please read on:
> I would suggest testing the proposed fix before fishing for other
> solutions?
That proposed "fix" is only a workaround, which has one serious
drawback: The server doesn't take the CA certificate revocation list
into account anymore. As this is a security issue, the proposed fix
(while it might work around the issue) is not feasible for us.
cu,
Sven
Luke Kanies
I don't know what the answer is, but my guess is that it's an apache
problem, not a Puppet problem -- if you can figure out how to make
apache deal with the csr correctly, you should be fine.
It might be that the csr needs to be reformatted or something, but I
doubt that's it.
--
One of the keys to happiness is a bad memory. -- Rita Mae Brown
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Sven Mueller
> On Nov 7, 2008, at 7:58 AM, Sven Mueller wrote:
>
>> James Turnbull schrieb:
>>> Sven Mueller wrote:
>>>> The comment by jamtur01 indicates he believes the problem to be a
>>>> configuration problem, and while bureado says that disabling the
>>>> SSLCARevocationFile statement in the apache config results in a
>>>> working
>>>> setup (which I wasn't able to verify yet), this information still
>>>> can't
>>>> be found on the "Using Mongrel" page. To repeat the symptoms:
>>> Not verify - does that mean not tested?
>> Yes, but please read on:
>>
>>> I would suggest testing the proposed fix before fishing for other
>>> solutions?
>> That proposed "fix" is only a workaround, which has one serious
>> drawback: The server doesn't take the CA certificate revocation list
>> into account anymore. As this is a security issue, the proposed fix
>> (while it might work around the issue) is not feasible for us.
>
>
> I don't know what the answer is, but my guess is that it's an apache
> problem, not a Puppet problem -- if you can figure out how to make
> apache deal with the csr correctly, you should be fine.
>
> It might be that the csr needs to be reformatted or something, but I
> doubt that's it.
Unfortunately, I don't know the details of Apache good enough to say
what goes on here, but I tried to find the reason online.
Hmm, retried it now, problem seems to be some signature problem:
[Mon Nov 10 08:47:20 2008] [warn] Invalid signature on CRL
[Mon Nov 10 08:47:20 2008] [error] Certificate Verification: Error (8):
CRL signature failure
I assume it is this problem:
http://osdir.com/ml/apache.mod-ssl.user/2002-06/msg00124.html
Which would mean that for some reason, the CRL is signed with a
different key than the client certificate. Could this be true?
regards,
Sven
Luke Kanies
Yeah, the CRL is signed with the CA certificate.
Maybe it shouldn't be? If so, this seems like an Apache bug, since
there doesn't seem to be any SSL requirement for this.
Alternatively, it might be that the client cert is capable of
verifying the CRL in some way, but, well, I don't really know. Anyone
willing to do the research?
--
Finn's Law:
Uncertainty is the final test of innovation.
Sven Mueller
>> Unfortunately, I don't know the details of Apache good enough to say
>> what goes on here, but I tried to find the reason online.
>>
>> Hmm, retried it now, problem seems to be some signature problem:
>> [Mon Nov 10 08:47:20 2008] [warn] Invalid signature on CRL
>> [Mon Nov 10 08:47:20 2008] [error] Certificate Verification: Error
>> (8):
>> CRL signature failure
>>
>> I assume it is this problem:
>> http://osdir.com/ml/apache.mod-ssl.user/2002-06/msg00124.html
>>
>> Which would mean that for some reason, the CRL is signed with a
>> different key than the client certificate. Could this be true?
>
> Yeah, the CRL is signed with the CA certificate.
Which sounds perfectly correct to me.
Who signs the client certificates then? The puppetmaster with its own
key? If so, this sounds wrong to me. Or the CRL should also be signed by
the puppetmasters own key.
> Maybe it shouldn't be? If so, this seems like an Apache bug, since
> there doesn't seem to be any SSL requirement for this.
The SSL requirement seems to be the DN of signing keys must be the same
for client cert and CRL. However I wonder in which cases the keys would
actually make sense to differ?
> Alternatively, it might be that the client cert is capable of
> verifying the CRL in some way, but, well, I don't really know. Anyone
> willing to do the research?
Hmm, if the client would need to verify its own certificate against the
CRL, how would that make SSL communication secure? The client could
still lie about its cert being (not) revoked. If anything, the server
needs to verify the client cert (while the client should verify the
server cert, but probably can't do so the way puppet SSL stuff works).
regards,
Sven