Skip to main content

Error validating server certificate / The certificate is not issued by a trusted authority

I was able to use SVN with ease (checkin, checkout, update code) until recently the SVN server went through some changes. I started to see the following on each SVN command:

Error validating server certificate for 'https://svn.myserver.com: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: de-v-svn
 - Valid: from ...
 - Issuer: I...
 - Fingerprint: ...
(R)eject, accept (t)emporarily or accept (p)ermanently?


It worked fine when I selected  (p)ermanently but had to do it again next time I used  SVN command.

Solution:
Delete ~/.subversion folder.
svn cleanup
svn up

Comments

Popular posts from this blog

svn credentials caching

SVN client has a built-in system for caching authentication credentials on disk. It saves the credentials in the user's private runtime configuration area ~/.subversion/auth/ (Unix-like systems) %APPDATA%/Subversion/auth/ (Windows) If you dont want to catch the credeitials for a commit, use --no-auth-cache. $ svn commit --no-auth-cache Here we are telling the svn client that dont cach authentication credentials. You can disable credential caching permanently by editing your runtime config file (located next to the auth/ directory). Set store-auth-creds to no. [auth] store-auth-creds = no

log4j - use logger instead of category

Do not use 'category'. In log4j 1.2, the Category class has marked as being deprecated and has been replaced by the Logger class. I am using log4j-1.2.14.jar and category didn't work for me. Example: <logger name="com.test.pkg1"><level value="INFO"/></logger> <logger name="com.test.pkg2"><level value="INFO"/></logger> Was: <category name="com.test.pkg1"><priority value="INFO"/></category> <category name="com.test.pkg2"><priority value="INFO"/></category>

Java Data Objects

JDO has nothing to do with where methods are executed. JDO simply specifies how the fields of a petent object should be managed in-memory, being transparently stored to and retrieved from an underlying datastore. With JDO, methods are invoked on persistent object by an application, as per any regular in-memory Java object. JDO has many implementations. Visit the following link to know about the available implementations. http://db.apache.org/jdo/impls.html