"Ошибка проверки сертификата сервера" при проверке SVN с помощью SvnAnt

Question

Я новичок в создании сценариев Ant. Я пытаюсь оформить заказ из репозитория SVN, используя скрипт Ant. Здесь, пожалуйста, найдите мой скрипт Ant ниже.

Я использую Дженкинс. Создал новый проект и установил invoke ant build, указав путь к файлу ant (цель ant - dist).

Я могу получить код от пользователя root и сделать это в Jenkinstools (Управление исходным кодом). Но при выполнении из сценария сборки Jenkins -> Ant показывается следующая ошибка:

Ошибка проверки сертификата сервера: сертификат выдан для другого имени хоста, издатель не является доверенным

<project name="ProjectBuid" basedir=".">

<description>
    simple example build file
</description>
<property environment="env" />
<property name="svn.username" value="NANI" />
<property name="svn.password" value="Pandu" />
<property name="code.base.location" value="${env.WORKSPACE}" />
<property name="lib.home" value="..\lib" />
<property name="{svnPathParam}" value="https://Ip:port/Build/" />

<property name="jenkins-url" value="http://IP1" />
<property name="auth-username" value="root" />
<property name="auth-pwd" value="1231231231231" />
<property name="cli.prefix" value="AB_CLI_" />

<path id="mvn.classpath">
    <pathelement location="${lib.home}\maven-ant-tasks-2.1.3.jar" />
</path>
<path id="svnant.classpath">
    <pathelement location="${lib.home}\svnant.jar" />
    <pathelement location="${lib.home}\svnClientAdapter.jar" />
    <pathelement location="${lib.home}\svnkit.jar" />
    <pathelement location="${lib.home}\ganymed.jar" />
    <pathelement location="${lib.home}\svnjavahl.jar" />
</path>

<tstamp>
    <format property="START_TIME" pattern="dd_MMM_yy_HH_mm_ss" />
</tstamp>
<property name="timestamp" value="${START_TIME}" />
<taskdef name="xmltask" classname="com.oopsconsultancy.xmltask.ant.XmlTask"
    classpath="${lib.home}\xmltask.jar" />
<taskdef resource="net/sf/antcontrib/antcontrib.properties">
    <classpath>
        <pathelement location="${lib.home}\ant-contrib-1.0b3.jar" />
    </classpath>
</taskdef>

<typedef resource="org/tigris/subversion/svnant/svnantlib.xml"
    classpathref="svnant.classpath" />
<svnSetting svnkit="false" javahl="false" id="svn.settings"
    username="${svn.username}" password="${svn.password}" />

<target name="dist" description="checkout code">
    <mkdir dir="${code.base.location}/${timestamp}" />
    <exec dir="${code.base.location}/${timestamp}" executable="svn">
        <arg value="co" />
        <arg value="${svnPathParam}" />
        <arg value="." />
    </exec>
    <!-- On executing above, error: Error validating server certificate for 
        'https://IP': [exec] - The certificate is not issued by a trusted authority. 
        Use the [exec] fingerprint to validate the certificate manually! [exec] - 
        The certificate hostname does not match. [exec] Certificate information: 
        [exec] - Hostname: IP [exec] - Valid: from XXXXXXX until yyyyyyyyyyyy [exec] 
        - Issuer: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [exec] - Fingerprint: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
        [exec] (R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS 
        of 'https://Ip/build': Server certificate verification failed: certificate 
        issued for a different hostname, issuer is not trusted (https://IP) <!--Or 
        and also tried as below -->
    <svn refid="svn.settings">
        <checkout url="${svnPathParam}" destPath="${code.base.location}\${timestamp}" />
    </svn>
    <!-- On choosing above, error: svn: OPTIONS of 'https://Ip/build': Server 
        certificate verification failed: certificate issued for a different hostname, 
        issuer is not trusted (https://IP) [svn] <Checkout> failed. -->
</target>

Answer 1

Правильное и правильное решение - использовать действующий сертификат, который соответствует полному доменному имени или имени хоста, которое вы используете для доступа к удаленному серверу. Все остальные предложения - просто обходные пути, и они довольно уродливы. Вы не должны обходить проверку сертификата, потому что это очень плохо с точки зрения безопасности.