similar to: ssl-proxy: client certificates and crl check

Hi I'm trying to use dovecot with client certificates. We produce our certificates with our on CA and we do NOT use certificate revocation lists. So I put "ssl_require_crl = no" into 10-ssl.conf. I did not find a solution neither in the wiki nor somewhere else, so I finally started to read the source. My impression is that openssl will always try to use CRLs. If

Hi all, As I reported earlier (with a typo in the work [BUG]) client certification validation *does not* work even if you do everything exactly according to all documentation and attempts at helpful advice. I have seen this issue with both startssl.com and self-signed certificates, and based on what I've seen from searching the web, this is a problem that has gotten little attention because

OK - trying to migrate to dovecot and I like what I see so far, but having a hard time getting it to work. I decided to go with the 1.0 version because I need to get away from the ~/Mail namespace. I'm trying to port from a Linuxconf virtual WU-IMAP type config. So - I compiled but then decided I wanted mysql so I tried to reconfigure and now getting compile errors. Looks like I'm

I'm compiling as I normally do. The config line for Dovecot is: configure --with-ldap --with-ssl --with-bzlib --with-zlib --with-stemmer --with-lucene --with-ldap followed by make & make install Then a 'configure' for Pigeonhole, followed by make, yields: libtool: link: gcc -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith

attempting to compile dovecot 2.2.31 on Sun/Oracle Solaris 10 SPARC. configure goes fine. First sign of problems during compile is with this warning: ............................................... *** libssl_iostream_openssl.so is not portable! ............................................... actual ERRORS - Soon, compile errors out with undefined symbols. Output at bottom of note.

Hi, I try to compile dovecot -2.2.24 on Fedora 31 and get the following error: iostream-openssl.c: In function ?openssl_iostream_verify_client_cert?: iostream-openssl.c:118:37: error: dereferencing pointer to incomplete type ?X509_STORE_CTX? {aka ?struct x509_store_ctx_st?} 118 | subject = X509_get_subject_name(ctx->current_cert); | ^~ make[3]: ***

> On 11/11/2019 17:22 Frank Elsner via dovecot <dovecot at dovecot.org> wrote: > > > Hi, > > I try to compile dovecot -2.2.24 on Fedora 31 and get the following error: > > iostream-openssl.c: In function ?openssl_iostream_verify_client_cert?: > iostream-openssl.c:118:37: error: dereferencing pointer to incomplete type ?X509_STORE_CTX? {aka ?struct

hello, I made a modification to ssl-proxy-openssl.c (patch attached) zo that it a) disconnects when no client certificate is presented b) checks the client certificate against the crl for our root cert. (so you can't use a revoked client cert.) c) returns the CommonName from the client cert. in ssl_proxy_get_peer_name (this way it's easier to use dovecot as imap-proxy with a

Is there a reason that CRL is required to exist in the ssl_ca_file? Could it just use it only if it's there, but otherwise ignore it? Or is this a bad idea? Is it even possible at all to tell that to OpenSSL? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message

On Thu, 21 Sep 2017 22:08:51 +0200 Peter L via samba <samba at lists.samba.org> wrote: > Thanks but I've actually tried that too. Not sure I put it in [kdc] > section though, I can try again. > > Den 21 sep. 2017 20:54 skrev "Andrew Bartlett" <abartlet at samba.org>: > > > On Thu, 2017-09-21 at 13:01 +0200, Peter L via samba wrote: > > >

Hello, As far as I can read in the Dovecot SSL configuration wiki page, each CA cert must be followed by the related CA CRL in the client certificate verification context ("ssl_ca_file" setting). In my company we do have our own PKI and as soon as Client certificate is compromised we do revoke it and update the related CA's CRL. Does that mean that I have to issue a new

Hi, I have a smartcard which is revoked in the Certificate Revocation List (CRL) but I can still login. Seams like the CRL check is not performed. Any known bug around this? Server setup: - Samba 4.4 on Debian as AD DC - Created domain MYDOM - smb.conf (extract): tls enabled = yes tls crlfile = tls/mycrl.pem (default is to look under private/ folder) Client setup: - Windows 7 machine as

https://bugzilla.mindrot.org/show_bug.cgi?id=2328 Bug ID: 2328 Summary: Per-user certificate revocation list (CRL) in authorized_keys Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: sshd

Ah, thank you, obviously this is a bug. Last comment (Łukasz Matyja 2016-04-01) says to have a fix, but how do I know if it has been added to bitbucket/samba? And if so, in which version? Or does the problem remain since the bugzilla case is still there? (Status: New) On Thu, Sep 21, 2017 at 10:52 PM, Rowland Penny via samba < samba at lists.samba.org> wrote: > On Thu, 21 Sep 2017

Thanks but I've actually tried that too. Not sure I put it in [kdc] section though, I can try again. Den 21 sep. 2017 20:54 skrev "Andrew Bartlett" <abartlet at samba.org>: > On Thu, 2017-09-21 at 13:01 +0200, Peter L via samba wrote: > > Hi, > > I have a smartcard which is revoked in the Certificate Revocation List > > (CRL) but I can still login. Seams

Hi! I'm new to this list and i could not find a way to search through the already posted articles, so please forgive me if this subject has been discussed before. Our security scanner stumbled over the IMAPs server i've set up recently using dovecot on a RedHat Enterprise 64bit Server. The security scanner found an error regarding a new SSL security leak named "BEAST". The

hello, can anyone help me? im gettitng this error when i tried runnin make on solaris 9 rm -f include/asterisk/version.h.tmp make[1]: `ast_expr.a' is up to date. make[1]: Leaving directory `/export/home/fst/chris/cvs/asterisk' gcc -g -o asterisk io.o sched.o logger.o frame.o loader.o config.o channel.o t ranslate.o file.o say.o pbx.o cli.o

# HG changeset patch # User Cristian Rodr?guez <crrodriguez at opensuse.org> # Date 1318533592 10800 # Node ID c15d6befe20082009cb40926afa208ab4b684818 # Parent 962df5d9413a4a0fcc68aacc1df0dca7a44a0240 Use SSL_MODE_RELEASE_BUFFERS if available to keep memory usage low. diff -r 962df5d9413a -r c15d6befe200 src/login-common/ssl-proxy-openssl.c --- a/src/login-common/ssl-proxy-openssl.c Wed

Today I've been trying to get dovecot (1.0 rc2) to use certificates for client side authentication. If my memory serves right, beta8 had no problems with it (although it was some time ago and on different machine). Similar setup works perfectly well for postfix (for authentication that is, on the same machine). Originally I thought I overdid some certificate settings (keyUsage, nsCertType,

# HG changeset patch # User David Hicks <david at hicks.id.au> # Date 1373085976 -36000 # Sat Jul 06 14:46:16 2013 +1000 # Node ID ccd83f38e4b484ae18f69ea08631eefcaf6a4a4e # Parent 1fbac590b9d4dc05d81247515477bfe6192c262c login-common: Add support for ECDH/ECDHE cipher suites ECDH temporary key parameter selection must be performed during OpenSSL context initialisation before ECDH and