svn won't accept my invalid certificate

Question

I have a server running apache with a self-signed certificate (the server) with subversion hooked in
It requires a username to checkout or update from the repo.
I have a checkout from the repo that I am trying to update on a cron job on two servers: server and client. Neither cron job will work for the same reason (I have almost the same setup on both, but the client is simpler).
The following are on client, where there is only one login: root (I know, please spare me the ridicule)
they are both gentoo if you think that matters

error

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

   (R)eject, accept (t)emporarily or accept (p)ermanently? 
svn: OPTIONS of 'https://server/svn/repo': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://server)

I know all this. That's why I followed all the guides to get svn to automatically accept the certificate:

/root/.subversion/servers

[global]
ssl-authority-files = /root/scripts/server.crt

/root/scripts/server.crt

-----BEGIN CERTIFICATE-----
MIIDejCCAmICCQDibo0twimetjANBgkqhkiG9w0BAQUFADB/MQswCQYDVQQGEwJV
UzERMA8GA1UECBMITmV3IFlvcmsxDDAKBgNVBAcTA05ZQzEjMCEGA1UEChMaSGFw
et al
-----END CERTIFICATE-----

/root/scripts/backup.sh

svn up /BACKUP/checkouts/server/ --username tom

And the command runs fine as root (no sudo, directly as root) with no prompting for confirming a certificate (it had previously, but I chose p for accept permanently).

Does anyone know why my script won't work? It's been annoying me for the past several months.

**Edit:**It's taken me a bit to get back to this, and I followed David's advice, but it still doesn't work. Now the error is:

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: server
 - Valid: from Sat, 20 Jun 2009 14:10:45 GMT until Mon, 20 Jun 2011 14:10:45 GMT
 - Issuer: Fake Company, New York, US
 - Fingerprint: 1a:c6:9c:eb:62:9e:e1:05:d9:d3:ac:01:f4:35:dc:00:14:48:e5:39
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://server/svn/folder': Server certificate verification failed: issuer is not trusted (https://server)

score 5 · Answer 1 · answered Jun 17 '09 at 08:13

5

Error validating server certificate for 'https://server:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Tom
 - Valid: from Sun, 01 Feb 2009 03:51:25 GMT until Tue, 01 Feb 2011 03:51:25 GMT
 - Issuer: Fake Company, NYC, New York, US
 - Fingerprint: fingerprint here

The problem is that your certificate does not match your server's hostname. You need the CN field in the certificate to match your hostname. In yuor case, your hostname is "server" and your certificate's CN is "Tom". You need to regenerate your certificate with the correct CN value.

answered Jun 17 '09 at 08:13

David Pashley

23,497
2
46
73

Sorry it's taken so long, but I tried this and it's still not working =/ – Tom Ritter Jul 14 '09 at 12:05
what does your certificate now say? – David Pashley Jul 14 '09 at 15:51
Ah, I see you've updated the question. Now your problem is that you're using a self-signed certificate. You can just accept this either for just this connection or for all time. If you press "p" it should just work. – David Pashley Jul 14 '09 at 15:57
1

If you want the cron job to work, you would probably have to do the checkout by hand once and accept the certificate. Then it should work. – David Pashley Jul 14 '09 at 16:00

score 2 · Answer 2 · answered Jan 19 '11 at 23:01

One thing to note - many cron jobs run w/ a different HOME (e.g. /etc/crontab (cron.daily etc) sets HOME=/) so it has a different .subversion file. Just bit us here and there was a /.subversion tree w/o the accepted cert. Setting HOME correctly in the cron script fixed it.

score 1 · Answer 3 · answered Mar 03 '21 at 21:23

1

just add this to the arguments

--trust-server-cert-failures="other,unknown-ca,cn-mistmatch,expired"

answered Mar 03 '21 at 21:23

ThaSami

11
1

score 1 · Answer 4 · answered Jul 14 '09 at 14:24

Did you try to set ssl-trust-default-ca to true? I dont know if will solve your problem but I saw this recomendation at Version Control with Subversion book.

Many OpenSSL installations also have a pre-defined set of “default” CAs that are nearly universally trusted. To make the Subversion client automatically trust these standard authorities, set the ssl-trust-default-ca variable to true.

score 0 · Answer 5 · edited Jan 30 '13 at 15:49

0

you can just:

echo t | svn update --username yourusername--password yourpassword --no-auth-cache /local.repository/path 2>/dev/null

edited Jan 30 '13 at 15:49

Kuf

449
2
8
25

answered Jan 28 '10 at 13:31

score 0 · Answer 6 · answered Jun 17 '09 at 03:45

0

There's a couple of solutions to get around the problem that come to mind. First, you could create a new webdav virtual host in Apache that does not use this certificate (plain http). Alternatively, you could use the svn+ssh access method and private key authentication for the cron job (may be a security risk).

I'd only go this route if you can't fix the problems with the certificate, or aren't tied to https webdav access though.

answered Jun 17 '09 at 03:45

Dana the Sane

828
10
19

I could (re)enable HTTP for only the internal network and still require HTTPS for external, hadn't thought of that. But I'm still hoping to get this working since there is a way I'm just doing something wrong. – Tom Ritter Jun 17 '09 at 03:51

score 0 · Answer 7 · answered May 25 '11 at 15:18

The answers to this question helped me assemble the pieces needed to solve a similar problem i was having. This is just to pre-assemble the pieces for other linux noobs like me.

to test the script you run via cron use

sudo su

instead of what I was using

sudo -s

otherwise the home directory and other variables won't be as when it is run by cron(root)

secondly don't use "--no-auth-cache". If you add that switch you can never permanently accept the certificate.

using the above, I was able to run the script once via sudo su, accept the certificate permanently and subsequent cron runs worked.

score 0 · Answer 8 · edited Mar 16 '13 at 01:51

0

You might try validating the certificate manually:

$ openssl x509 -noout -fingerprint -in cert.pub
MD5 Fingerprint=0D:89:07:D6:4F:BC:84:2E:2E:14:C2:DA:D4:3B:D5:7C

edited Mar 16 '13 at 01:51

answered Jul 17 '11 at 19:14

Inturbidus

101
1

score 0 · Answer 9 · answered Mar 16 '13 at 10:41

Put this in your script:

# svn up /BACKUP/checkouts/server/ --username tom –config-dir /xyz/zyx

config-dir could be anything where you want to store the certificate information. Before running it from the cron, run it manually and accept the certificate permanently, using "p".

Once accepted, run it through cron and I believe it will work like a charm.

There is one more option (if previous option doesn't work by any chance), which is kind of risky in other environments, but in your environment, it should be fine. Use the script something like this:

# svn up /BACKUP/checkouts/server/ --username tom --non-interactive –-trust-server-cert

This will simply accept the certificate without bothering. This is not advised in the production environment because this is kind of a security risk, but in your case, where you are using self made certificate, you can use it.

Source: GeekRide

svn won't accept my invalid certificate

9 Answers9