Le ven. 19 juil. 2019 à 20:44, Stefan Sperling <stsp_at_elego.de> a écrit :
>
> 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.
Hi,
Sorry for the delay and thanks a lot for the answers.
In fact, I did read about the non-interactive option but this question
[1] made me thought it wouldn't work. Having tried with
--trust-server-cert and got errors, I thought this was it. I didn't
saw there also was a --trust-server-cert-failures. I should have
better read the docs and see one can specify the nature of the error
to silent in order to consider the certificate as trustable !
I'm now able to proceed in non-interactive mode on the new instance
accessing the svn-server. Thanks. However, I couldn't find a way to
store the password. Of course, this is non-interactive mode.
Nonetheless, could it be a way to store the credentials ? If so this
would save me some time to tweak the scripts (and the need to export
credentials variables before running the scripts).
About the interactive prompt omitting the (p)ermanently save in case
of 'other' errors, you're right on spot, the class 'other' appeared as
reported errors in the instance running 1.10.4. I did a little more
investigation now that I better understand the inner functioning of
the certificate validation. What's really strange is that the error
nature changed from svn 1.10.2 to 1.10.4 while accessing the same svn
server, and thus, the same certificate. It's a self signed
certificate, and is rightly considered so in 1.10.2, as not trustable,
but is reported as an unknown certificate error in 1.10.4 (as the logs
attests). This would clearly explain why the (p)ermanently option
disappeared. Nonetheless, I wonder why « unknown authority error » is
now reported as « other error » in 1.10.4. Was it meant or is it a
regression ?
pierre_at_edtv-01-pierre:~$ svn --version
svn, version 1.10.2 (r1835932)
compiled Aug 4 2018, 16:28:03 on x86_64-pc-linux-gnu
pierre@edtv-01-pierre:~$ LANG=C svn co https://svn.---.fr/--- ---
Error validating server certificate for 'https://svn.---.fr:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
- The certificate has expired.
(R)eject, accept (t)emporarily or accept (p)ermanently?
pierre_at_edtv-08-pierre:~$ svn --version
svn, version 1.10.4 (r1850624)
compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu
pierre@edtv-08-pierre:~$ LANG=C svn co https://svn.---.fr/--- ---
Error validating server certificate for 'https://svn.---.fr:443':
- The certificate hostname does not match.
- The certificate has expired.
- The certificate has an unknown error.
Certificate information:
(R)eject or accept (t)emporarily?
Best Regards,
Pierre.
[1] https://unix.stackexchange.com/questions/318169/svn-automatically-accept-server-certificate
Received on 2019-07-26 21:55:45 CEST