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.
