View Issue Details

IDProjectCategoryView StatusLast Update
0004020unrealircdpublic2015-05-18 17:21
ReporterJobe Assigned Tosyzop  
Status resolvedResolutionfixed 
Fixed in Version3.4-alpha2 
Summary0004020: SSL Client Certificate Fingerprint Command
DescriptionThis request compliments and extends item 0004019

Simple request for a command to allow a user to get their SSL client certificate fingerprint, or to allow an oper to get anybodies SSL client certificate fingerprint.

Attached is a module that provides such a command (must be loaded on all servers)
TagsNo tags attached.
3rd party modules


related to 0004019 resolvedsyzop SSL Client Certificate Fingerprint Authentication 
related to 0004110 resolvedsyzop Extended user information 



2011-05-11 17:05


m_fingerprint.c (4,169 bytes)


2011-05-13 21:53

reporter   ~0016651

I really like this, Jobe! No more distributing client certificates to servers. Excellent!


2011-05-16 06:42

reporter   ~0016652

I think this should be expanded in the future to maybe adding fingerprint information to WHOIS or allow anyone to get a user's fingerprint.

Not only would the ability for everyone to have access to this command aid in the addition of oper/vhost/allow blocks, but it would also be an extremely useful tool for users to know they are talking to the same person (if said person is using their own cert for the connection)


2011-05-16 11:28

reporter   ~0016653

Last edited: 2011-05-16 11:29

View 2 revisions

Hmmm I didn't think of that when I added the oper only functionality to get someone elses fingerprint.

Is easy enough to modify to allow anyone to get anyones fingerprint.

But yes adding it to /whois would be nice too, although itd only be available in remote /whois, same way as idle times are, for obvious reasons.

That is unless Unreal somehow propagated the fingerprint at user introduction like InspIRCd does


2012-02-26 22:24

administrator   ~0016927

I know I'm kinda hijacking this bugid now, but would there be any use for a fingerprint extban?

If we would use it for more things than just a command to show it and ircop/auth check, then we might want to set it in the user struct instead of calculating (or grabbing it) through OpenSSL each time.

I guess all those questions are interlinked... do we want to show the FP in /WHOIS. Are there any ircds that do? It doesn't sound like a bad idea per se.


2012-02-26 22:27

reporter   ~0016928

IMO including SSL fingerprints in WHOIS is a must, as that's half the reason to add them to the IRCd (clients could then store finger prints and use stored fingerprints to verify the authenticity of users later).

I think an extban would be better as a module not in the core distribution.

I do believe both these would probably be best if it is stored in the struct, it would be a waste of process resources to generate the fingerprint every time it is requested.


2012-02-27 16:20

reporter   ~0016931

I quite agree, it should be retrieved and calculated at connection only, thereafter it should be found in the user struct. Feel free to expand and extend as you see fit (not that you need my permission of course :P)


2012-03-06 05:01

reporter   ~0016940

If we had this globally, then it would be easy to add support for SASL EXTERNAL (using certificate fingerprint with SASL.).


2015-05-18 17:20

administrator   ~0018315

This is now implemented in /WHOIS.

Issue History

Date Modified Username Field Change
2011-05-11 17:05 Jobe New Issue
2011-05-11 17:05 Jobe File Added: m_fingerprint.c
2011-05-12 01:55 ohnobinki Severity minor => feature
2011-05-12 01:55 ohnobinki Description Updated View Revisions
2011-05-13 21:53 warg Note Added: 0016651
2011-05-16 06:42 Stealth Note Added: 0016652
2011-05-16 11:28 Jobe Note Added: 0016653
2011-05-16 11:29 Jobe Note Edited: 0016653 View Revisions
2012-02-26 22:24 syzop Note Added: 0016927
2012-02-26 22:27 Stealth Note Added: 0016928
2012-02-27 16:20 Jobe Note Added: 0016931
2012-03-06 05:01 nenolod Note Added: 0016940
2012-05-07 18:27 syzop Assigned To => syzop
2012-05-07 18:27 syzop Status new => confirmed
2012-05-07 18:28 syzop Relationship added related to 0004019
2012-05-07 18:42 syzop Relationship added related to 0004110
2015-05-18 17:20 syzop Note Added: 0018315
2015-05-18 17:20 syzop Status confirmed => resolved
2015-05-18 17:20 syzop Fixed in Version => 3.4-alpha2
2015-05-18 17:20 syzop Resolution open => fixed