MonitorWare Knowledge Base

saispo wrote:response to my question... :

Code: Select all

8179.987151999:b7e0f930: GTLS CA file: '/etc/syslog-ca/ca.pem'
8179.989563849:b7e0f930: unexpected GnuTLS error -64 in nsd_gtls.c:517: Error while reading file.


Well if that file exists, did you copy that from your Certificate Authority server?

You are suppose to have at least 3 servers for this.
Server 1: Your certificate Authority
Server 2: your rsyslogd central log server
Server 3: an rsyslogd client

You generate ca.pem on server 1, then copy that to server 2 and server 3.

On server 2 and 3, you generate an key and ca-request, and then using the ca.pem that you copied over you generate a cert.

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

I am pretty sure I went through the steps ok, but I'm getting this error in the client:

6707.563922000:main queue:Reg/w0: Called LogError, msg: not permitted to talk to peer, certificate invalid: insecure algorithm
6707.563954000:main queue:Reg/w0: logmsg: flags 5, from 'ec2-67-202-50-123', msg not permitted to talk to peer, certificate invalid: insecure algorithm: Connection refused

And this on the server:
6676.057463000:imtcp.c: Called LogError, msg: info on invalid cert: peer provided 1 certificate(s). Certificate 1 info: certificate valid from Wed Jun 18 11:45:44 2008 to Sat Jun 16 11:45:53 2018; Certificate public key: RSA; DN: C=US,O=Digital Fountain,OU=Operations,L=Fremont,ST=CA,CN=ea.dfountain.local; Issuer DN: C=US,O=Digital Fountain,OU=Operations,L=Fremont,ST=CA,CN=ea.dfountain.local,EMAIL=xxx@yyy.com; SAN:DNSname: ec2-67-202-50-123.compute-1.amazonaws.com;

Basically, on the CA, I generated a private key, a ca cert, copied the ca cert to the syslog client and server, generated the certs and keys for the individual servers (on the CA machine), copied them out to their respective hosts, set up the rsyslog.conf to point to the right places, then added the bit from earlier in the thread about x509 to the client and server configs.

Any idea where I'm going wrong?
Thanks a lot

I took a look at the code and it seem that error means the certificate wasn't signed.. but I went through the signing process of generating a request and then signing it before copying out the resulting certs..

On CA:
certtool --generate-privkey --outfile ca-key.pem
certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca.pem

mkdir ec2-67-202-50-123 (server)
cd ec2-67-202-50-123
certtool --generate-privkey --outfile key.pem
certtool --generate-request --load-privkey key.pem --outfile request.pem
certtool --generate-certificate --load-request request.pem --outfile cert.pem --load-ca-certificate ../ca.pem --load-ca-privkey ../ca-key.pem

Then I did the same procedure for the client.. the for both, I copied out the common ca.pem and the individual cert.pem and key.pem files, added them to the rsyslog.conf. Here is the conf for the server:

$ModLoad immark.so # provides --MARK-- message capability
$ModLoad imudp.so # provides UDP syslog reception
$ModLoad imtcp.so # provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imuxsock.so # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so # provides kernel logging support (previously done by rklogd)


# make gtls driver the default
$DefaultNetstreamDriver gtls

# certificate files
$DefaultNetstreamDriverCAFile /etc/tls/ca.pem
$DefaultNetstreamDriverCertFile /etc/tls/cert.pem
$DefaultNetstreamDriverKeyFile /etc/tls/key.pem

#$ModLoad /root/rsyslog-3.19.7/plugins/imtcp/.libs/imtcp.so # load listener

$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerRun 10514 # start up listener at port 10514
$AllowedSender TCP, 10.0.0.0/8

$InputTCPServerStreamDriverAuthMode x509/name
$InputTCPServerStreamDriverPermittedPeer *.amazonaws.com

*.* /var/log/messages

And for the client:

$ModLoad immark.so # provides --MARK-- message capability
$ModLoad imudp.so # provides UDP syslog reception
#$ModLoad imtcp.so # provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imuxsock.so # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so # provides kernel logging support (previously done by rklogd)


# certificate files - just CA for a client
$DefaultNetstreamDriverCAFile /etc/tls/ca.pem

# Need these on client?
$DefaultNetstreamDriverCertFile /etc/tls/cert.pem
$DefaultNetstreamDriverKeyFile /etc/tls/key.pem



$ActionSendStreamDriverAuthMode x509/name
$ActionSendStreamDriverPermittedPeer ec2-75-101-249-167.compute-1.amazonaws.com



# set up the action
$DefaultNetstreamDriver gtls # use gtls netstream driver
$ActionSendStreamDriverMode 1 # require TLS for the connection
*.* @@(o)10.254.202.118:10514 # send (all) messages


Thanks again for any help

mixtli wrote:I am pretty sure I went through the steps ok, but I'm getting this error in the client:

6707.563922000:main queue:Reg/w0: Called LogError, msg: not permitted to talk to peer, certificate invalid: insecure algorithm
6707.563954000:main queue:Reg/w0: logmsg: flags 5, from 'ec2-67-202-50-123', msg not permitted to talk to peer, certificate invalid: insecure algorithm: Connection refused

And this on the server:
6676.057463000:imtcp.c: Called LogError, msg: info on invalid cert: peer provided 1 certificate(s). Certificate 1 info: certificate valid from Wed Jun 18 11:45:44 2008 to Sat Jun 16 11:45:53 2018; Certificate public key: RSA; DN: C=US,O=Digital Fountain,OU=Operations,L=Fremont,ST=CA,CN=ea.dfountain.local; Issuer DN: C=US,O=Digital Fountain,OU=Operations,L=Fremont,ST=CA,CN=ea.dfountain.local,EMAIL=xxx@yyy.com; SAN:DNSname: ec2-67-202-50-123.compute-1.amazonaws.com;

Basically, on the CA, I generated a private key, a ca cert, copied the ca cert to the syslog client and server, generated the certs and keys for the individual servers (on the CA machine), copied them out to their respective hosts, set up the rsyslog.conf to point to the right places, then added the bit from earlier in the thread about x509 to the client and server configs.

Any idea where I'm going wrong?
Thanks a lot

Well the "info on invalid cert" is the same error I'm getting. I'm not sure if thats saying the Certificate Authority is the problem or if the hostname of the certificate is the problem or what. I'd be nice if it said exactly what info was invalid.

Rainer, are you able to add anymore debug info with rsyslog for that? Did you come across that error in the lab at all?


For the first error you mentioned, what version of certtool do you have? 2.3.11?
# certtool -v
certtool (GnuTLS 2.3.11) 2.3.11

certtool (GnuTLS 2.0.4) 2.0.4

stock package for ubuntu hardy. Is that bad?

mixtli wrote:certtool (GnuTLS 2.0.4) 2.0.4

stock package for ubuntu hardy. Is that bad?

Not sure if its "bad", but I think it might be using a different algorithm:
certificate invalid: insecure algorithm: Connection refused

I am using CentOS with gnuTLS 2.3.11

Try regenerating the certs with 2.3.11 and see if that error doesn't go away:
http://www.gnu.org/software/gnutls/rele ... 11.tar.bz2

upgraded gnu-tls, recreated certs.. same problem exactly

mixtli wrote:upgraded gnu-tls, recreated certs.. same problem exactly

Shoot, sorry for making you do that then. But we had to eliminate that as a variable.

Hopefully Rainer will have some good info for us when he wakes up.

Sorry... this week is very busy for me, I am trying my best to follow, but it takes a little time. I'll provide some quick pointers, but I mainly create the doc while doing so. That's more structured and of better use.

Quick info: the gnu version should not be an issue - I initially (under Fedora developed with 1.6something and now (under Fedora 9) use 2something, so that should be fine. I'll begin to create doc now (as answers to the posts) and post these links when they are ready. Thanks for your persistence, this is very useful.

Rainer

OK, here is some information on the error messages:

http://www.rsyslog.com/doc-tls_cert_errmsgs.html

Next, I'll look at the certificate generation process.

Rainer

... and now we have the doc on how to generate the CA files:

http://www.rsyslog.com/doc-tls_cert_ca.html

and the individual machine certificates:

http://www.rsyslog.com/doc-tls_cert_machine.html

Both tested in my lab and work well. They are not perfect, but keep you going. These are actual records of what I did. More doc coming up later. Feedback appreciated. It is very important to use exactly the parameters shown (except for cert validity and names, of course). When I departed from some of them, I got all sorts of interesting error messages later in the process (-48 is also something that you can see frequently).

Rainer

Thanks! Those docs are great!

Its saying certificate invalid still though, with "no specific reason".

I followed your docs to a T, any idea why it thinks the cert is invalid?

2008-06-19T07:10:49.884370-05:00 lds143 rsyslogd:not permitted to talk to peer, certificate invalid: no specific reason: Resource temporarily unavailable
2008-06-19T07:10:49.889724-05:00 lds143 rsyslogd:info on invalid cert: peer provided 1 certificate(s). Certificate 1 info: certificate valid from Thu Jun 19 07:03:28 2008 to Wed Mar 16 07:03:35 2011; Certificate public key: RSA; DN: C=US,O=SecureHost,OU=Online,L=Chicago,ST=IL,CN=xxx.xxxhost.com; Issuer DN: C=US,O=SecureHost,OU=Online,L=Chicago,ST=IL,CN=xxx; SAN:DNSname: xxx.xxxhost.com;

abefroman wrote:2008-06-19T07:10:49.884370-05:00 lds143 rsyslogd:not permitted to talk to peer, certificate invalid: no specific reason: Resource temporarily unavailable

This scares me, too I am investigating. At worst, I may need to check if I can get some more specifics on the error from GnuTLS...

Back to doc: we are gradually getting closer. Here is the server config "guide"

http://www.rsyslog.com/doc-tls_cert_server.html

Rainer

An update on the "no specific reason" error:

The actual message is generated by rsyslog (not GnuTLS, as I thought), but it generates it based on a return state from GnuTLS. In short, I do not have any more information available at what is going wrong. So I can not display any better error message. I have instrumented rsyslog to get GnuTLS debug messages. From them, it looks like there is a problem decrypting the certificate AND it looks like the meaningless error message is intentional - a better message may help an attacker to succeed. I have contacted the GnuTLS mailing list if they can offer any advise.

What I am still puzzled about is why this occurs in the first place. If the certificates are generated in the same way, they should behave the same way...

Rainer