On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote:
> On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourès 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.
>
> If you're scripting 'svn' you should be using the --non-interactive option.
>
> In which case your script can use the --trust-server-cert-failures
> option to accept a cert in pre-determined failure cases.
>
> 'svn help update', for example, displays the following information
> section about the --trust-server-cert-failures option:
>
> --trust-server-cert-failures ARG : with --non-interactive, accept SSL server
> certificates with failures; ARG is comma-separated
> list of 'unknown-ca' (Unknown Authority),
> 'cn-mismatch' (Hostname mismatch), 'expired'
> (Expired certificate), 'not-yet-valid' (Not yet
> valid certificate) and 'other' (all other not
> separately classified certificate errors).
>
> Once your script uses this option it should work out of the box against
> your problematic server and there should be no need to save the cert.
Follow-up regarding your actual question:
It looks like the interactive prompt omits an option to save the cert
if it sees a certificate failure of class 'other' from the above list.
I am not sure why this decision was made but that's what the current
code seems to do. So I suspect your SSL cert is failing for some reason
other than unknown-ca, cn-mismatch, expired, not-yet-valid.
Additionally, the ability to save a cert is also disabled if the
--no-auth-cache option is used.
Received on 2019-07-19 20:45:07 CEST