Le sam. 20 juil. 2019 à 16:55, Nico Kadel-Garcia <nkadel_at_gmail.com> a écrit :
>
> On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès <pierre.foures_at_gmail.com> wrote:
> >
> > Hi all,
> >
> > I have a script accessing an old svn server whom SSL certificate have
> > expired a long time ago. Up to now, I was permanently accepting the
> > certificate on the first run of the script and then everything was
> > sailling smooth. I reinstalled a couple of months ago a new box where
> > this script was intented to run and the (p)ermanently option seems not
> > provided anymore.
>
> Negotiating certificate trust can be fun. Can you sidestep the whole
> issue by switching to svn+sh? Or get new, signed certificates?
>
> > Thankfully, I still have the "old" running box to double-check, and
> > the (p)ermanently option is still present. Both boxes are Debian
> > Buster (but was installed as unstable, before the official release).
> > The (p)ermanently option was also present in svn on previous versions
> > of Debian.
> >
> > I can notice that the versions of svn changed between my old and new
> > box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the
> > change-log [1] and it doesn't seem specified this option has been
> > removed. I also gave a look on openssl version and it went upgraded
> > from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal
> > of the (p)ermanently option is linked or not the openssl upgrade.
> >
> > If some of you have an hint and an half to explain how and why this
> > option disapeared, that would be really nice. I wonder if it was meant
> > or not, to see where I'm headed.
> >
> > More over, I would really appreciate if someone could share a solution
> > to still permanently accept the certificate on the new box, as for
> > now, I can't use this box and the old one should soon be
> > decommissioned.
>
> Stefan has correctly pointed out ways to get your client, at run-time,
> to accept failed certificates. But what is stopping you from replacing
> the certificate?
It's on the todo-list for quite a long time but never find it ways to
get to prime time. We decided to migrate this server to a new
infrastructure and it will benefits from automatically renewed Let's
Encrypt certificates. That will eventually address all points. But as
things works well and wouldn't add significant benefits, we didn't
haven't scheduled the operation so far.
The server is running smooth and used only for internal use, so by the
time Let's Encrypt wasn't here, we didn't felt to spent some money on
buying a certificate from a trusted authority. As self certificates
(rightly) reported an error, we already had to « accept permanently »
the certificate when we was re-configuring a new client instance. Then
the certificate expired. This added one line in the warnings, but
didn't really change a thing for us, so we didn't felt the urge to
renew the certificate. We knew which it was and we trusted it.
More over, the encountered problem seems that the self-signed
certificate switched from being reported as "not trusted" to "unknown
error". The cause then seems rooted in the self certification, so I'm
not sure issuing a new self-signed certificate would solve the problem
?
Best Regards,
Pierre.
Received on 2019-07-26 22:11:54 CEST