similar to: New SSL certificate! Does it require reload or restart?

On 31 Jul 2024, at 0:05, Steve Matzura wrote: > I tried everything, including changing the name of the new PEM containing the properly concatenated certificates as specified in the Icecast configuration. The reload command did not, does not appear to, re-read the certificate file even though the filename has been changed. To make it work, I had to restart the Icecast server in the usual

I tried everything, including changing the name of the new PEM containing the properly concatenated certificates as specified in the Icecast configuration. The reload command did not, does not appear to, re-read the certificate file even though the filename has been changed. To make it work, I had to restart the Icecast server in the usual manner. Is this a bug or is it by design?

Hi, On 14.03.19 09:33, Yassine Chaouche via dovecot wrote: > On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: >> The general answere here is try and see, as you could totally test it >> on your own. The certificate is read at startup and put in memory for >> the rest of the execution time. Dovecot won't monitor the file for >> changes on disk, as this

The general answere here is try and see, as you could totally test it on your own. The certificate is read at startup and put in memory for the rest of the execution time. Dovecot won't monitor the file for changes on disk, as this would waste CPU cycles and make dovecot only slower for no reason. The process (or person) that changes the file is responsible to restart dovecot to reload

Running dovecot 2.2, apologies if this question has been asked before: I've done the research but couldn't find anything. I run a server that uses dovecot as a MUA for Postfix and have a Let's Encrypt certificate that auto-renews through certbot on Ubuntu server 16.04. Dovecot did not pick up on the new certificate for the hostname. It did after a restart. To be clear: Let's

On Thu, Mar 14, 2019, at 12:09 PM, Yassine Chaouche via dovecot wrote: > On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote: > > > [...] the way we have configured exim, it neither needs reload or > > restart but reads the certificate file every time it has to use it. > > What happens if you goof off in the middle of an opeartion, temporarily > putting a wrong file

On Thu, Mar 14, 2019, at 11:33 AM, Yassine Chaouche via dovecot wrote: > On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: > > The general answere here is try and see, as you could totally test it > > on your own. The certificate is read at startup and put in memory for > > the rest of the execution time. Dovecot won't monitor the file for > > changes on

On 3/14/19 9:32 AM, Yassine Chaouche via dovecot wrote: > The general answere here is try and see, as you could totally test it > on your own. The certificate is read at startup and put in memory for > the rest of the execution time. Dovecot won't monitor the file for > changes on disk, as this would waste CPU cycles and make dovecot only > slower for no reason. The process

On 3/14/19 9:55 AM, Patrick Cernko via dovecot wrote: > [...] the way we have configured exim, it neither needs reload or > restart but reads the certificate file every time it has to use it. What happens if you goof off in the middle of an opeartion, temporarily putting a wrong file instead of the new certificate, and exim starts delivering the new broken certificate right away ? or

Hi, On 7/13/24 04:59, Thomas Jensen wrote: > I am runninghttps://radio.horsens-garage.rocks:8443. Ok. > If I test horsens-garage.rocks in a "Test-Your-SSL" > site, there are no problems. But if I test radio.horsens- > garage.rocks:8443, it report invalide date. horsens-garage.rocks != radio.horsens-garage.rocks, BUT, according to the testing site you're using

Yup, that did the trick. Thanks! Filipe On 1/10/19 7:47 AM, Aki Tuomi wrote: > > > On 10.1.2019 9.42, Filipe Carvalho wrote: >> >> Hello, >> >> Not sure if this is the right place to post this, but the ssl >> certificate of the repo.dovecot.org server expired on the 9th of January. >> >> It's giving an error via the browser and via the apt

Hi Dovecot-gurus With the introduction of LE certificates the certificate renewal cycle is a lot faster, unfortunately even a "dovecot reload" cuts the existing connections when doing the cert updates, which is quite frustrating - and yes most clients automatically reconnect but still... Is any work going into implementing a more ?graceful reload? for dovecot like the one for nginx

Hi Dovecot-gurus With the introduction of LE certificates the certificate renewal cycle is a lot faster, unfortunately even a "dovecot reload" cuts the existing connections when doing the cert updates, which is quite frustrating - and yes most clients automatically reconnect but still... Is any work going into implementing a more ?graceful reload? for dovecot like the one for nginx

On Mon, Jun 15, 2015 at 07:38:26AM -0400, Steve Matzura wrote: > If I could remove this message from this list, I would! I just figured > out what my problem was, and it's something I thought *FOR SURE* I had > fixed. I've looked at this thing so many times, I fell into the trap > of not seeing the forest for the trees. I had inadvertently omitted > the '<' before

Am Montag, den 15.06.2015, 07:38 -0400 schrieb Steve Matzura: > If I could remove this message from this list, I would! I just figured > out what my problem was, and it's something I thought *FOR SURE* I had > fixed. I've looked at this thing so many times, I fell into the trap > of not seeing the forest for the trees. I had inadvertently omitted > the '<' before

According to https://icecast.org/docs/icecast-2.4.1/config-file.html: ssl If et to 1 will enable HTTPS on this listen-socket. Icecast must have been compiled against openSSL to be able to do so. Does the standard Icecast ditribution include SSL support, or must it be built manually to include this? I've read articles saying both are true. Which is correct?

Someone, I don't remember whether it was Alex or Urban, asked me to check on my private keyfile to see if it began with "Begin RSA private key". I reported that it does not. Now here's where things get strange: When I ran the command: $ openssl req -nodes -newkey rsa:2048 -sha1 -keyout myserver.key -out server.csr on an old Ubuntu system, `myserver.key' does begin with

Is there any way to make Dovecot 2.2.22 not require a client SSL certificate for a local IMAP connection, but require it for any remote IMAP connection? My server is configured to require client certificates: ssl = required ... auth_ssl_require_client_cert = yes I tried adding the following to create an exception for localhost: remote 127.0.0.1 { ? ssl = no ? auth_ssl_require_client_cert =

On Mon, Jun 15, 2015 at 09:32:39AM -0400, Steve Matzura wrote: > What is the reasoning behind that `<' anyway? It just appears so odd > that a path should have that at its front. I would guess: - make it clearer it's a file and not a string - follow similar syntax as input redirection in sh/perl/.. B

Hi. I've spent the past few hours trying to get SSL working right in Dovecot 1.0.5 and now I must turn to you for help. I purchased an SSL certificate from Go Daddy. I pointed ssl_cert_file to the .crt file and ssl_key_file to the .key file, but the client (Mail.app) complains: Mail was unable to verify the identity of this server, which has a certificate issued to