Mike, I think you misunderstood/I didn’t explain myself well. I’ve got the SSL portion working well; if the client has a signed cert, I get a string back, if it doesn’t, I fall back to a generic string (or “null”).
Do I do something strange to get my data into an interceptor: http://flume.apache.org/FlumeUserGuide.html#flume-interceptors Or do I just go ahead and patch the append method of AvroSource.java to add another header if the private variable is set. I’ve posted sample code to the bug report I filed: https://issues.apache.org/jira/browse/FLUME-2204 Is AvroSource instantiated for every connection? https://github.com/apache/flume/blob/flume-1.4/flume-ng-core/src/main/java/org/apache/flume/source/AvroSource.java -Charles On Jan 30, 2014, at 7:21 PM, Mike Percy <mpe...@apache.org<mailto:mpe...@apache.org>> wrote: I am not an expert in the JSSE API, so without specifics regarding APIs you are trying to use I don't think I can be of much help. From browsing around a little bit, it looks like we can simply have the server specify the CA certs that it respects and the client will attempt to use one of the certs in its store that is signed by one of them. Maybe this StackOverflow thread will help? http://stackoverflow.com/questions/3712366/choosing-ssl-client-certificate-in-java Also the JSSE reference guide: http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html And of course, the Flume Avro Source (check the Netty pipeline factory part): https://github.com/apache/flume/blob/trunk/flume-ng-core/src/main/java/org/apache/flume/source/AvroSource.java#L452 The logic you are describing regarding a fallback CA sounds somewhat complicated. I'd bet you can make those requirements fit into how the JSSE API was designed and have it require only one SSL handshake sequence by having the server specify multiple acceptable CAs to the client. On Thu, Jan 30, 2014 at 12:29 AM, Pritchard, Charles X. -ND <charles.x.pritchard....@disney.com<mailto:charles.x.pritchard....@disney.com>> wrote: I need to put the CN on the cert into a variable; it's essentially an authenticated string the server knows to be valid (since it has been signed). I'd like to route messages to a directory based on the string or otherwise send them to a fallback directory on a failed cert. ________________________________________ From: Mike Percy [mpe...@apache.org<mailto:mpe...@apache.org>] Sent: Wednesday, January 29, 2014 6:44 PM To: user@flume.apache.org<mailto:user@flume.apache.org> Subject: Re: Adding SSL peer cert info to AvroSource If it's using a signed cert then what do you need to put into the filter? You mean a list of allowed peers? If so then you could either try to piggyback on the IpFilter and make it accept hostnames, or yes add another filter config option such as hostFilter. Mike On Wed, Jan 29, 2014 at 12:23 PM, Pritchard, Charles X. -ND <charles.x.pritchard....@disney.com<mailto:charles.x.pritchard....@disney.com><mailto:charles.x.pritchard....@disney.com<mailto:charles.x.pritchard....@disney.com>>> wrote: I’m trying to add in the feature to expose the client’s peer cert into AvroSource: https://apache.googlesource.com/flume/+/trunk/flume-ng-core/src/main/java/org/apache/flume/source/AvroSource.java Per the bug request I filed in October: https://issues.apache.org/jira/browse/FLUME-2204 Any ideas on how I might expose the data — it’s just a string for the CN from the peer cert. I’m having a difficult time figuring out how to expose this connection state information so that Flume’s configuration magic can take hold from there. It seems a little like I need to create yet-another-filter, kind of like IpFilter. Any pointers? The CN info may be used to route to a particular directory (in an HDFS sink) and/or set a header for the AvroEvent, or possibly just validate a header (header.CN == ssl peer CN or FAIL). -Charles