Как установить jarsigner в Linux

Обновлено: 21.11.2024

OpenJDK — это один из многих комплектов Java Development Kit (JDK), поддерживаемых в Red Hat Enterprise Linux для использования с корпоративными продуктами JBoss. В этой задаче показано, как установить OpenJDK в Red Hat Enterprise Linux и как настроить систему для использования его в качестве JDK по умолчанию.

Примечание

Перед выполнением этой задачи необходимо выполнить следующие условия:

Вы должны использовать Red Hat Enterprise Linux 6. В настоящее время OpenJDK недоступен и не поддерживается для Red Hat Enterprise Linux 5.

Установите RPM OpenJDK.

Существует два разных способа установки RPM, в зависимости от того, использовали ли вы интерфейс командной строки (CLI) или графический интерфейс пользователя (GUI).

Из интерфейса командной строки

Из графического интерфейса

Выполните поиск openjdk и выберите параметр java-1.6.0-openjdk-devel для OpenJDK 6 или параметр java-1.7.0-openjdk-devel для OpenJDK 7.

Необязательно: задайте переменную среды JAVA_HOME.

Некоторые приложения, такие как Apache Maven и Apache Ant, требуют установки переменной среды JAVA_HOME. Если вам нужно это сделать, выполните следующие действия.

Определите правильное значение для JAVA_HOME . Red Hat Enterprise Linux устанавливает OpenJDK 1.6 либо в /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/, либо в /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/. , в зависимости от того, является ли ваша система 32-битной или 64-битной архитектурой. JAVA_HOME должен указывать на каталог, содержащий исполняемый файл bin/java.

Как пользователь, который будет использовать OpenJDK, откройте файл конфигурации оболочки. Для оболочки Bash это файл /home/username/.bashrc .

В нижней части файла введите следующую строку, заменив гипотетический путь фактическим путем для использования в вашей системе: export JAVA_HOME replaceable">/path/to/java/home"

Переключайтесь между разными версиями OpenJDK с помощью утилиты альтернатив.

Red Hat Enterprise Linux включает утилиту под названием альтернативы, которая позволяет изменить версию по умолчанию для приложений, допускающих установку нескольких версий. OpenJDK — одно из таких приложений.

Чтобы использовать утилиту альтернатив, выполните следующие действия. Обратите внимание, что установка переменных среды переопределяет поведение команды альтернатив. Например, если вы используете скрипт, который вручную устанавливает переменные $JAVA_HOME и $JAVA в другой JDK, отличный от того, который указан командой альтернатив, переменные среды переопределяют команду.

Команда альтернатив не установлена по умолчанию, но может быть уже установлена в вашей системе. Если нет, установите альтернативный пакет, выполнив следующую команду:

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

jarsigner использует информацию о ключе и сертификате из хранилища ключей для создания цифровых подписей для файлов JAR. Хранилище ключей — это база данных закрытых ключей и связанных с ними цепочек сертификатов X.509, аутентифицирующих соответствующие открытые ключи. Утилита keytool используется для создания и администрирования хранилищ ключей.

jarsigner использует закрытый ключ объекта для создания подписи. Подписанный файл JAR содержит, среди прочего, копию сертификата из хранилища ключей для открытого ключа, соответствующего закрытому ключу, использованному для подписи файла. jarsigner может проверить цифровую подпись подписанного файла JAR, используя сертификат внутри него (в его файле блока подписи).

В настоящее время jarsigner может подписывать только JAR-файлы, созданные JAR-инструментом JDK, или zip-файлы. (Файлы JAR аналогичны zip-файлам, за исключением того, что они также имеют файл META-INF/MANIFEST.MF. Такой файл будет автоматически создан, когда jarsigner подписывает zip-файл.)

По умолчанию jarsigner подписывает JAR-файл. Вместо этого используйте параметр -verify для проверки подписанного JAR-файла.

Совместимость с JDK 1.1

Инструменты keytool и jarsigner полностью заменяют инструмент javakey из JDK 1.1. Эти новые инструменты предоставляют больше возможностей, чем javakey, включая возможность защиты хранилища ключей и закрытых ключей с помощью паролей, а также возможность проверки подписей в дополнение к их созданию.

Новая архитектура хранилища ключей заменяет базу данных удостоверений, созданную и управляемую javakey. Нет обратной совместимости между форматом хранилища ключей и форматом базы данных, используемым javakey в версии 1.1.Однако:

< tr valign="top">

Тег	Описание
o	Можно импортировать информацию из базы данных удостоверений в хранилище ключей с помощью команды keytool -identitydb
o	jarsigner может подписывать файлы JAR, также ранее подписанные с помощью javakey
o	jarsigner может проверять файлы JAR, подписанные с помощью javakey. Таким образом, он распознает и может работать с псевдонимами подписавших, которые взяты из базы данных идентификаторов JDK 1.1, а не из хранилища ключей JDK 1.2. .

В следующей таблице объясняется, как файлы JAR, подписанные в JDK 1.1.x, обрабатываются на платформе Java 2.

Примечания:

Тег	Описание
1.	Если идентификатор/псевдоним упоминается в файле политики, его необходимо импортировать в хранилище ключей для файла политики иметь какое-либо влияние на предоставленные привилегии.
1.	Если в файл политики, он должен быть импортирован в хранилище ключей, чтобы файл политики имел какое-либо влияние на предоставленные привилегии.
2.	Комбинация файла политики и хранилища ключей имеет приоритет перед доверенным удостоверением в базе данных удостоверений.
3.	Ненадежные идентификаторы игнорируются на платформе Java 2.
4.	Только доверенные удостоверения можно импортировать в хранилища ключей Java 2 SDK.

Псевдонимы хранилища ключей

Все объекты хранилища ключей доступны через уникальные псевдонимы.

При использовании jarsigner для подписи файла JAR необходимо указать псевдоним для записи хранилища ключей, содержащей закрытый ключ, необходимый для создания подписи. Например, следующее подпишет файл JAR с именем MyJARFile.jar, используя закрытый ключ, связанный с псевдонимом Duke в хранилище ключей с именем mystore в «рабочем» каталоге. Поскольку выходной файл не указан, MyJARFile.jar перезаписывается подписанным файлом JAR.

Хранилища ключей защищены паролем, поэтому необходимо указать пароль хранилища (в данном случае myspass). Вам будет предложено ввести его, если вы не укажете его в командной строке. Точно так же закрытые ключи защищены в хранилище ключей паролем, поэтому пароль закрытого ключа (в данном случае dukekeypasswd) должен быть указан, и вам будет предложено ввести его, если вы не укажете его в командной строке и он не совпадает с паролем магазина.

Расположение хранилища ключей

jarsigner имеет параметр -keystore для указания имени и расположения используемого хранилища ключей. Хранилище ключей по умолчанию хранится в файле с именем .keystore в домашнем каталоге пользователя, что определяется системным свойством user.home.

Обратите внимание, что входной поток из параметра -keystore передается в метод KeyStore.load. Если в качестве URL-адреса указано NONE, то методу KeyStore.load передается нулевой поток. Необходимо указать NONE, если хранилище ключей не является файловым, например, если оно находится на аппаратном токен-устройстве.

Реализация хранилища ключей

Класс KeyStore, предоставляемый в пакете java.security, предоставляет четко определенные интерфейсы для доступа и изменения информации в хранилище ключей. Возможно существование нескольких различных конкретных реализаций, каждая из которых предназначена для определенного типа хранилища ключей.

Существует встроенная реализация по умолчанию, предоставленная Sun Microsystems. Он реализует хранилище ключей в виде файла, используя проприетарный тип (формат) хранилища ключей с именем «JKS». Он защищает каждый закрытый ключ своим индивидуальным паролем, а также защищает целостность всего хранилища ключей с помощью (возможно, другого) пароля.

Реализации хранилища ключей зависят от поставщика. В частности, интерфейсы приложений, предоставляемые KeyStore, реализованы с точки зрения «интерфейса поставщика услуг» (SPI). То есть существует соответствующий абстрактный класс KeystoreSpi, также в пакете java.security, который определяет методы интерфейса поставщика услуг, которые должны реализовать «поставщики». (Термин «поставщик» относится к пакету или набору пакетов, которые предоставляют конкретную реализацию подмножества сервисов, доступ к которым может получить Java Security API.) Таким образом, чтобы обеспечить реализацию хранилища ключей, клиенты должны реализовать поставщика и предоставить реализацию подкласса KeystoreSpi, как описано в разделе Как реализовать поставщика для архитектуры криптографии Java.

Приложения могут выбирать различные типы реализации хранилища ключей от разных поставщиков, используя фабричный метод getInstance, предоставленный в классе KeyStore.Тип хранилища ключей определяет способ хранения и формат данных информации о хранилище ключей, а также алгоритмы, используемые для защиты закрытых ключей в хранилище ключей и целостность самого хранилища ключей. Реализации хранилища ключей разных типов несовместимы.

keytool работает с любой реализацией хранилища ключей на основе файлов. (Он обрабатывает расположение хранилища ключей, переданное ему в командной строке, как имя файла и преобразует его в FileInputStream, из которого загружает информацию о хранилище ключей.) С другой стороны, инструменты jarsigner и policytool могут считывать хранилище ключей из любое местоположение, которое можно указать с помощью URL.

Для jarsigner и keytool тип хранилища ключей можно указать в командной строке с помощью параметра -storetype. Для инструмента политики вы можете указать тип хранилища ключей с помощью команды «Изменить хранилище ключей» в меню «Правка».

Если вы явно не укажете тип хранилища ключей, инструменты выберут реализацию хранилища ключей просто на основе значения свойства keystore.type, указанного в файле свойств безопасности. Файл свойств безопасности называется java.security и находится в каталоге свойств безопасности java.home/lib/security, где java.home — это каталог среды выполнения (каталог jre в SDK или каталог верхнего уровня). каталог среды выполнения Java 2).

Каждый инструмент получает значение keystore.type, а затем проверяет все установленные в данный момент поставщики, пока не найдет тот, который реализует хранилища ключей этого типа. Затем он использует реализацию хранилища ключей от этого поставщика.

Класс KeyStore определяет статический метод с именем getDefaultType, который позволяет приложениям и аплетам извлекать значение свойства keystore.type. Следующая строка кода создает экземпляр типа хранилища ключей по умолчанию (как указано в свойстве keystore.type):

KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

Тип хранилища ключей по умолчанию — "jks" (собственный тип реализации хранилища ключей, предоставленный Sun). Это указывается следующей строкой в файле свойств безопасности:

keystore.type=jks

Чтобы инструменты использовали реализацию хранилища ключей, отличную от используемой по умолчанию, измените эту строку, указав другой тип хранилища ключей.

Например, если у вас есть пакет провайдера, предоставляющий реализацию хранилища ключей для типа хранилища ключей "pkcs12", измените строку на

keystore.type=pkcs12

Примечание: регистр не имеет значения в обозначениях типов хранилища ключей. Например, "JKS" будет считаться тем же, что и "jks".

Поддерживаемые алгоритмы и размеры ключей

В настоящее время jarsigner может подписывать JAR-файл, используя тег

	Описание
o	Алгоритм цифровой подписи (DSA) с алгоритмом дайджеста SHA-1, или
o	алгоритм RSA с алгоритмом дайджеста MD5.

То есть, если открытый и закрытый ключи подписывающей стороны являются ключами DSA, jarsigner попытается подписать файл JAR, используя алгоритм SHA-1/DSA. Если ключи подписывающей стороны являются ключами RSA, jarsigner подпишет файл JAR, используя алгоритм MD5/RSA. Это возможно только при наличии статически установленного провайдера, предоставляющего реализацию алгоритма MD5/RSA. (Всегда доступен алгоритм SHA-1/DSA от поставщика "SUN" по умолчанию.)

Подписанный файл JAR

Когда jarsigner используется для подписи JAR-файла, выходной подписанный JAR-файл точно такой же, как и входной JAR-файл, за исключением того, что он содержит два дополнительных файла, помещенных в каталог META-INF:

< td valign="bottom">файл блока подписи с расширением .DSA. < td colspan="2">Файл подписи (файл .SF) похож на файл манифеста, который всегда включается в файл JAR, созданный инструментом jar. То есть для каждого исходного файла, включенного в файл JAR, в файле .SF есть три строки, как и в файле манифеста, в которых перечислено следующее:

Тег	Описание
o	файл подписи с расширением .SF и
o
Имена базовых файлов для этих двух файлов основаны на значении параметр -sigFile. Например, если параметр отображается как
-sigFile MKSIGN
файлы называются MKSIGN.SF и MKSIGN.DSA.
Если в командной строке не отображается параметр -sigfile, базовое имя файла для .SF и Файлы .DSA будут состоять из первых 8 символов псевдонима, указанного в командной строке, все они будут преобразованы в верхний регистр. Если имя псевдонима содержит менее 8 символов, используется полное имя псевдонима. Если псевдоним содержит какие-либо символы, недопустимые в имени файла подписи, каждый такой символ преобразуется в символ подчеркивания ("_") при формировании имени файла. Допустимые символы включают буквы, цифры, знаки подчеркивания и дефисы.
Файл подписи (.SF)
o	имя файла,
o	имя используемого алгоритма дайджеста (SHA) и
o	значение дайджеста SHA.< /td>

В файле манифеста значение дайджеста SHA для каждого исходного файла является дайджестом (хэшем) двоичных данных в исходном файле. С другой стороны, в файле .SF значением дайджеста для данного исходного файла является хэш трех строк в файле манифеста для исходного файла.

Файл подписи также по умолчанию включает заголовок, содержащий хэш всего файла манифеста. Наличие заголовка позволяет оптимизировать проверку, как описано в разделе Проверка файла JAR.

Файл блока подписи (.DSA)

Файл .SF подписан, и подпись помещена в файл .DSA. Файл .DSA также содержит закодированный внутри сертификат, удостоверяющий подлинность открытого ключа, соответствующего закрытому ключу, используемому для подписи.

Проверка файла JAR

Файл .SF по умолчанию включает заголовок, содержащий хэш всего файла манифеста. Когда заголовок присутствует, проверка может проверить, действительно ли хэш в заголовке соответствует хешу файла манифеста. В этом случае проверка переходит к следующему шагу.

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

Несколько подписей для файла JAR

Файл JAR может быть подписан несколькими людьми, просто запустив инструмент jarsigner для файла несколько раз, каждый раз указывая псевдоним для другого человека, например:

Если файл JAR подписан несколько раз, в итоговом файле JAR будет несколько файлов .SF и .DSA, по одной паре для каждой подписи. Таким образом, в приведенном выше примере выходной файл JAR включает файлы со следующими именами:

Примечание. JAR-файл также может иметь смешанные подписи, некоторые из которых создаются инструментом javakey JDK 1.1, а другие — jarsigner. То есть jarsigner можно использовать для подписи файлов JAR, уже ранее подписанных с помощью javakey.

Различные параметры jarsigner перечислены и описаны ниже. Примечание.

< tr valign="top"> < td valign="bottom">Параметры -keystore, -storepass, -keypass, -sigfile и -signedjar имеют значение только при подписании файла JAR, а не при проверке подписанного файла JAR. Точно так же псевдоним указывается только в командной строке при подписании файла JAR.

Тег	Описание
o	Всем именам опций предшествует знак минус (-).
o	Параметры могут указываться в любом порядке.
o	Элементы, выделенные курсивом (значения параметров), представляют фактические значения, которые должны быть предоставлены.
o

Тег	Описание
-keystore URL	Указывает URL-адрес, указывающий расположение хранилища ключей. По умолчанию это файл .keystore в домашнем каталоге пользователя, как определено системным свойством user.home. При подписании требуется хранилище ключей, поэтому вы должны явно указать его, если хранилище ключей по умолчанию не существует (или вы хотите использовать хранилище, отличное от значения по умолчанию). Хранилище ключей не требуется при проверке, но если оно указано или существует значение по умолчанию, а также указан параметр -verbose, выводится дополнительная информация о том, являются ли сертификаты, используемые для проверки файла JAR, действительными. содержится в этом хранилище ключей. Примечание: аргумент -keystore на самом деле может быть спецификацией имени файла (и пути), а не URL-адресом, и в этом случае он будет обрабатываться так же, как URL-адрес «файл:». То есть -keystore filePathAndName рассматривается как эквивалент -keystore file:filePathAndName Символы в файле должны быть из набора "a-zA-Z0-9_-". То есть допускаются только буквы, цифры, символы подчеркивания и дефиса. Примечание. Все символы нижнего регистра будут преобразованы в верхний регистр для имен файлов .SF и .DSA. Можно проверить файлы JAR, подписанные с помощью jarsigner, инструмента javakey JDK 1.1 или обоих. По умолчанию этот заголовок добавляется в целях оптимизации.Когда заголовок присутствует, то всякий раз, когда файл JAR проверяется, проверка может сначала проверить, действительно ли хэш в заголовке соответствует хэшу всего файла манифеста. Если это так, проверка переходит к следующему шагу. Если нет, необходимо выполнить менее оптимизированную проверку того, что хэш в каждом разделе информации об исходном файле в файле .SF равен хешу соответствующего раздела в файле манифеста. Дополнительную информацию см. в разделе Проверка файла JAR. Подписание файла JAR Предположим, у вас есть JAR-файл с именем bundle.jar, и вы хотите подписать его с помощью закрытого ключа пользователя, чей псевдоним хранилища ключей — «jane» в хранилище ключей с именем «mystore» в «рабочем» каталоге. Предположим, пароль хранилища ключей — «myspass», а пароль для закрытого ключа Джейн — «j638klm». Вы можете использовать следующее, чтобы подписать файл JAR и назвать подписанный файл JAR "sbundle.jar": Обратите внимание, что в приведенной выше команде не указан параметр -sigfile, поэтому сгенерированные файлы .SF и .DSA, которые будут помещены в подписанный файл JAR, будут иметь имена по умолчанию, основанные на имени псевдонима. То есть они будут называться JANE.SF и JANE.DSA. Если вы хотите получить запрос на ввод пароля магазина и пароля закрытого ключа, вы можете сократить приведенную выше команду до Если используемое хранилище ключей является хранилищем ключей по умолчанию (с именем .keystore в вашем домашнем каталоге), вам не нужно указывать хранилище ключей, как в следующем примере: Наконец, если вы хотите, чтобы подписанный JAR-файл просто перезаписывал входной JAR-файл (bundle.jar), вам не нужно указывать параметр -signedjar: Проверка подписанного файла JAR Чтобы проверить подписанный файл JAR, то есть убедиться, что подпись действительна и что файл JAR не был изменен, используйте следующую команду: Если проверка прошла успешно отображается. В противном случае появится сообщение об ошибке. Вы можете получить больше информации, если воспользуетесь параметром -verbose. Пример использования jarsigner с параметром -verbose показан ниже вместе с образцом вывода: Подтверждение информации о сертификате Если вы укажете параметр -certs при проверке вместе с параметрами -verify и -verbose, выходные данные будут включать информацию о сертификате для каждого лица, подписавшего файл JAR, включая тип сертификата, информацию об отличительном имени подписывающего лица (если оно сертификат X.509), а в скобках — псевдоним хранилища ключей для подписавшего, если сертификат открытого ключа в файле JAR совпадает с сертификатом в записи хранилища ключей. Например, Если сертификат подписывающей стороны не является сертификатом X.509, информация об отличительном имени отсутствует. В этом случае отображаются только тип сертификата и псевдоним. Например, если сертификат является сертификатом PGP, а псевдоним "bob", вы получите Проверка JAR-файла, включающего подписанты баз данных удостоверений Если файл JAR был подписан с помощью инструмента JDK 1.1 javakey, и, таким образом, подписывающее лицо является псевдонимом в базе данных удостоверений, выходные данные проверки включают символ "i". Если файл JAR был подписан как псевдонимом в базе данных удостоверений, так и псевдонимом в хранилище ключей, отображаются как "k", так и "i". При использовании параметра -certs любые псевдонимы базы данных удостоверений отображаются в квадратных скобках, а не в круглых скобках, которые используются для псевдонимов хранилища ключей. Например: Обратите внимание, что псевдоним "Герцог" заключен в скобки, чтобы указать, что это псевдоним базы данных удостоверений, а не псевдоним хранилища ключей. Вы используете инструмент jarsigner для подписи и проверки файлов Java Archive (JAR). Параметры командной строки. См. Параметры для jarsigner. Опция -verify может принимать ноль или более псевдонимов хранилища ключей после имени файла JAR. Если указан параметр -verify, команда jarsigner проверяет, соответствует ли сертификат, используемый для проверки каждой подписанной записи в файле JAR, одному из псевдонимов хранилища ключей. Псевдонимы определяются в хранилище ключей, указанном параметром -keystore, или в хранилище ключей по умолчанию. Если вы также укажете параметр -strict и команда jarsigner обнаружит серьезные предупреждения, отобразится сообщение "jar проверено, с ошибками подписанта". Подписываемый JAR-файл. Если вы также указали параметр -strict и команда jarsigner обнаружила серьезные предупреждения, отобразится сообщение "jar подписано с ошибками подписанта". Псевдонимы определяются в хранилище ключей, указанном параметром -keystore, или в хранилище ключей по умолчанию. У инструмента jarsigner две цели: Чтобы подписать файлы архива Java (JAR). Чтобы проверить подписи и целостность подписанных файлов JAR. Функция JAR позволяет упаковывать файлы курсов, изображения, звуки и другие цифровые данные в один файл для более быстрого и удобного распространения. Инструмент jar позволяет разработчикам создавать файлы JAR.(Технически любой файл ZIP также может считаться файлом JAR, хотя при создании командой jar или обработке командой jarsigner файлы JAR также содержат файл META-INF/MANIFEST.MF.) Цифровая подпись – это строка битов, которая вычисляется на основе некоторых данных (подписываемых данных) и закрытого ключа объекта (лица, компании и т. д.). Подобно собственноручной подписи, цифровая подпись имеет много полезных характеристик: Его подлинность можно проверить с помощью вычислений, в которых используется открытый ключ, соответствующий закрытому ключу, используемому для создания подписи. Его нельзя подделать, если закрытый ключ хранится в секрете. Это функция подписанных данных, поэтому ее нельзя считать подписью и для других данных. Подписанные данные изменить нельзя. Если данные изменены, подлинность подписи не может быть проверена. Чтобы сгенерировать подпись объекта для файла, объект должен сначала иметь связанную с ним пару открытого и закрытого ключей и один или несколько сертификатов, удостоверяющих подлинность его открытого ключа. Сертификат – это заявление с цифровой подписью от одного объекта, в котором говорится, что открытый ключ другого объекта имеет определенное значение. Команда jarsigner использует информацию о ключе и сертификате из хранилища ключей для создания цифровых подписей для файлов JAR. Хранилище ключей — это база данных закрытых ключей и связанных с ними цепочек сертификатов X.509, которые аутентифицируют соответствующие открытые ключи. Команда keytool используется для создания и администрирования хранилищ ключей. Команда jarsigner использует закрытый ключ объекта для создания подписи. Подписанный файл JAR содержит, среди прочего, копию сертификата из хранилища ключей для открытого ключа, соответствующего закрытому ключу, использованному для подписи файла. Команда jarsigner может проверить цифровую подпись подписанного файла JAR, используя сертификат внутри него (в его файле блока подписи). Команда jarsigner может генерировать подписи, содержащие отметку времени, которая позволяет системам или программам развертывания (включая подключаемый модуль Java) проверять, был ли подписан файл JAR, когда сертификат подписи все еще действителен. Хотя подключаемый модуль Java доступен и поддерживается в JDK 9, он помечен как устаревший в связи с подготовкой к удалению в будущем выпуске. Альтернативы аплетам и встроенным приложениям JavaFX, для которых требуется подключаемый модуль, включают Java Web Start и автономные приложения. Кроме того, API позволяют приложениям получать информацию о метках времени. В настоящее время команда jarsigner может подписывать только файлы JAR, созданные с помощью команды jar, или файлы zip. Файлы JAR аналогичны zip-файлам, за исключением того, что они также имеют файл META-INF/MANIFEST.MF. Файл META-INF/MANIFEST.MF создается, когда команда jarsigner подписывает ZIP-файл. По умолчанию команда jarsigner подписывает JAR- или ZIP-файл. Используйте параметр -verify для проверки подписанного JAR-файла. Команда jarsigner также пытается проверить сертификат подписывающей стороны после подписания или проверки. В случае ошибки проверки или любой другой проблемы команда генерирует предупреждающие сообщения. Если вы укажете параметр -strict, команда будет рассматривать серьезные предупреждения как ошибки. См. Ошибки и предупреждения. Все объекты хранилища ключей доступны с уникальными псевдонимами. При использовании команды jarsigner для подписи файла JAR необходимо указать псевдоним для записи хранилища ключей, которая содержит закрытый ключ, необходимый для создания подписи. Если выходной файл не указан, исходный файл JAR перезаписывается подписанным файлом JAR. Хранилища ключей защищены паролем, поэтому необходимо указать пароль хранилища. Вам будет предложено ввести его, если вы не укажете его в командной строке. Точно так же закрытые ключи защищены в хранилище ключей паролем, поэтому пароль закрытого ключа должен быть указан, и вам будет предложено ввести пароль, если вы не укажете его в командной строке, и он не совпадает с хранилищем. пароль. Команда jarsigner имеет параметр -keystore для указания URL-адреса используемого хранилища ключей. Хранилище ключей по умолчанию хранится в файле с именем .keystore в домашнем каталоге пользователя, что определяется системным свойством user.home. Oracle Solaris, Linux и OS X: : user.home по умолчанию указывает домашний каталог пользователя. Входной поток из параметра -keystore передается методу KeyStore.load. Если в качестве URL-адреса указано NONE, то методу KeyStore.load передается нулевой поток. NONE следует указывать, если класс KeyStore не основан на файлах, например, когда он находится на аппаратном токен-устройстве. Класс KeyStore, предоставляемый в пакете java.security, предоставляет ряд четко определенных интерфейсов для доступа и изменения информации в хранилище ключей. У вас может быть несколько разных конкретных реализаций, каждая из которых предназначена для определенного типа хранилища ключей. В настоящее время существует два инструмента командной строки, которые используют реализации хранилища ключей ( keytool и jarsigner ). Вы также можете использовать инструмент policytool с графическим интерфейсом, но он устарел и может быть удален в будущем выпуске JDK. . Поскольку класс KeyStore общедоступен, пользователи JDK могут создавать дополнительные приложения безопасности, использующие его. Реализация хранилища ключей по умолчанию — PKCS12. Это кроссплатформенное хранилище ключей, основанное на стандарте синтаксиса обмена личной информацией RSA PKCS12. Этот стандарт в первую очередь предназначен для хранения или транспортировки закрытых ключей пользователя, сертификатов и различных секретов. Существует еще одна встроенная реализация, предоставленная Oracle. Он реализует хранилище ключей в виде файла с проприетарным типом (форматом) хранилища ключей с именем JKS. Он защищает каждый закрытый ключ своим индивидуальным паролем, а также защищает целостность всего хранилища ключей с помощью (возможно, другого) пароля. Реализации хранилища ключей основаны на поставщиках, что означает, что интерфейсы приложений, предоставляемые классом хранилища ключей, реализуются с точки зрения интерфейса поставщика услуг (SPI). Существует соответствующий абстрактный класс KeystoreSpi, также в пакете java.security, который определяет методы интерфейса поставщика услуг, которые должны реализовать поставщики. Термин «поставщик» относится к пакету или набору пакетов, которые предоставляют конкретную реализацию подмножества сервисов, к которым может обращаться Java Security API. Чтобы обеспечить реализацию хранилища ключей, клиенты должны реализовать поставщика и предоставить реализацию подкласса KeystoreSpi, как описано в разделе «Как реализовать поставщика в архитектуре криптографии Java». Приложения могут выбирать различные типы реализации хранилища ключей от разных поставщиков с помощью фабричного метода getInstance в классе KeyStore. Тип хранилища ключей определяет способ хранения и формат данных информации хранилища ключей, а также алгоритмы, используемые для защиты закрытых ключей в хранилище ключей и целостность самого хранилища ключей. Реализации хранилища ключей разных типов несовместимы. Команды jarsigner и policytool могут считывать файловые хранилища ключей из любого места, которое можно указать с помощью URL-адреса. Кроме того, эти команды могут считывать нефайловые хранилища ключей, например те, что предоставляются MSCAPI в Windows и PKCS11 на всех платформах. Для команд jarsigner и keytool можно указать тип хранилища ключей в командной строке с параметром -storetype. Для Инструмента политики вы можете указать тип хранилища ключей с помощью команды «Редактировать» в меню «Хранилище ключей». Если вы явно не укажете тип хранилища ключей, инструменты выберут реализацию хранилища ключей на основе значения свойства keystore.type, указанного в файле свойств безопасности. Файл свойств безопасности называется java.security и находится в каталоге свойств безопасности JDK, java.home/conf/security . Каждый инструмент получает значение keystore.type, а затем проверяет все установленные поставщики, пока не найдет тот, который реализует хранилища ключей этого типа. Затем он использует реализацию хранилища ключей от этого поставщика. Класс KeyStore определяет статический метод с именем getDefaultType, который позволяет приложениям и аплетам извлекать значение свойства keystore.type. Следующая строка кода создает экземпляр типа хранилища ключей по умолчанию, как указано в свойстве keystore.type: Тип хранилища ключей по умолчанию — pkcs12 . Это кроссплатформенное хранилище ключей, основанное на стандарте синтаксиса обмена личной информацией RSA PKCS12. Это указывается следующей строкой в файле свойств безопасности: Регистр не имеет значения в обозначениях типов хранилища ключей. Например, JKS — это то же самое, что и jks . Чтобы инструменты использовали реализацию хранилища ключей, отличную от используемой по умолчанию, вы можете изменить эту строку, указав другой тип хранилища ключей. Например, если вы хотите использовать реализацию хранилища ключей Oracle jks, измените строку на следующую: По умолчанию команда jarsigner подписывает файл JAR, используя один из следующих файлов алгоритмов в зависимости от типа и размера закрытого ключа: Java и JVM (виртуальная машина Java) широко используются и требуются для многих типов программного обеспечения. Эта статья проведет вас через процесс установки и управления различными версиями Java с помощью apt-get . Предпосылки Чтобы следовать этому руководству, вам потребуется: Один сервер Ubuntu 16.04. Пользователь sudo без полномочий root, которого можно настроить, следуя руководству по первоначальной настройке сервера Ubuntu 16.04. Установка JRE/JDK по умолчанию Самый простой способ установки Java – использовать версию, поставляемую вместе с Ubuntu. В частности, будет установлена последняя и рекомендуемая версия OpenJDK 8. Сначала обновите индекс пакета. Далее установите Java. В частности, эта команда установит среду выполнения Java (JRE). Есть еще одна установка Java по умолчанию, которая называется JDK (Java Development Kit). JDK обычно требуется только в том случае, если вы собираетесь компилировать Java-программы или если это требуется программному обеспечению, которое будет использовать Java. JDK содержит JRE, поэтому при установке JDK вместо JRE нет никаких недостатков, за исключением большего размера файла. Вы можете установить JDK с помощью следующей команды: Установка Oracle JDK Если вы хотите установить Oracle JDK, официальную версию, распространяемую Oracle, вам потребуется выполнить еще несколько шагов. Сначала добавьте Oracle PPA, а затем обновите репозиторий пакетов. Затем, в зависимости от версии, которую вы хотите установить, выполните одну из следующих команд: Oracle JDK 8 Это последняя стабильная версия Java на момент написания статьи и рекомендуемая версия для установки. Вы можете сделать это с помощью следующей команды: Oracle JDK 9 Это предварительная версия для разработчиков, а общий выпуск запланирован на март 2017 года. Не рекомендуется использовать эту версию, так как в ней все еще могут быть проблемы с безопасностью и ошибки. Дополнительную информацию о Java 9 можно найти на официальном веб-сайте JDK 9. Чтобы установить JDK 9, используйте следующую команду: Управление Java На одном сервере может быть несколько установок Java. Вы можете настроить версию по умолчанию для использования в командной строке с помощью update-alternatives , который определяет, какие символические ссылки используются для разных команд. Вывод будет выглядеть примерно следующим образом. В этом случае это то, как будут выглядеть выходные данные со всеми установленными версиями Java, упомянутыми выше. Теперь вы можете выбрать номер, который будет использоваться по умолчанию. Это также можно сделать для других команд Java, таких как компилятор ( javac ), генератор документации ( javadoc ), средство подписи JAR ( jarsigner ) и многое другое. Вы можете использовать следующую команду, заполнив команду, которую хотите настроить. Настройка переменной среды JAVA_HOME Многие программы, например серверы Java, используют переменную среды JAVA_HOME для определения места установки Java. Чтобы установить эту переменную среды, нам сначала нужно выяснить, где установлена Java. Вы можете сделать это, выполнив ту же команду, что и в предыдущем разделе: Скопируйте путь из предпочтительной установки, а затем откройте /etc/environment с помощью nano или вашего любимого текстового редактора. В конце этого файла добавьте следующую строку, заменив выделенный путь собственным скопированным путем. Сохраните и закройте файл, а затем перезагрузите его. Теперь вы можете проверить, установлена ли переменная среды, выполнив следующую команду: Это вернет путь, который вы только что установили. Заключение Теперь вы установили Java и знаете, как управлять различными ее версиями. Теперь вы можете устанавливать программное обеспечение, работающее на Java, например Tomcat, Jetty, Glassfish, Cassandra или Jenkins. Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean! Присоединяйтесь к нашему сообществу DigitalOcean, насчитывающему более миллиона разработчиков, бесплатно! Получайте помощь и делитесь знаниями в нашем разделе "Вопросы и ответы", находите руководства и инструменты, которые помогут вам расти как разработчику и масштабировать свой проект или бизнес, а также подписывайтесь на интересующие вас темы. Читайте также: Что такое Windows 10 Advanced Professional Asus vivobook 15 установка windows 10 с флешки Как закрепить панель задач внизу экрана Windows 10, чтобы она не исчезала Rise of the Tomb Raider не запускается на Windows 10 Как увеличить насыщенность цвета в Windows 10 Контакты Политика конфиденциальности

Тег

Описание

-keystore URL

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

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

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

Примечание: аргумент -keystore на самом деле может быть спецификацией имени файла (и пути), а не URL-адресом, и в этом случае он будет обрабатываться так же, как URL-адрес «файл:». То есть

-keystore filePathAndName

рассматривается как эквивалент

-keystore file:filePathAndName

Символы в файле должны быть из набора "a-zA-Z0-9_-". То есть допускаются только буквы, цифры, символы подчеркивания и дефиса. Примечание. Все символы нижнего регистра будут преобразованы в верхний регистр для имен файлов .SF и .DSA.

Можно проверить файлы JAR, подписанные с помощью jarsigner, инструмента javakey JDK 1.1 или обоих.

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

Дополнительную информацию см. в разделе Проверка файла JAR.

Подписание файла JAR

Предположим, у вас есть JAR-файл с именем bundle.jar, и вы хотите подписать его с помощью закрытого ключа пользователя, чей псевдоним хранилища ключей — «jane» в хранилище ключей с именем «mystore» в «рабочем» каталоге. Предположим, пароль хранилища ключей — «myspass», а пароль для закрытого ключа Джейн — «j638klm». Вы можете использовать следующее, чтобы подписать файл JAR и назвать подписанный файл JAR "sbundle.jar":

Обратите внимание, что в приведенной выше команде не указан параметр -sigfile, поэтому сгенерированные файлы .SF и .DSA, которые будут помещены в подписанный файл JAR, будут иметь имена по умолчанию, основанные на имени псевдонима. То есть они будут называться JANE.SF и JANE.DSA.

Если вы хотите получить запрос на ввод пароля магазина и пароля закрытого ключа, вы можете сократить приведенную выше команду до

Если используемое хранилище ключей является хранилищем ключей по умолчанию (с именем .keystore в вашем домашнем каталоге), вам не нужно указывать хранилище ключей, как в следующем примере:

Наконец, если вы хотите, чтобы подписанный JAR-файл просто перезаписывал входной JAR-файл (bundle.jar), вам не нужно указывать параметр -signedjar:

Проверка подписанного файла JAR

Чтобы проверить подписанный файл JAR, то есть убедиться, что подпись действительна и что файл JAR не был изменен, используйте следующую команду:

Если проверка прошла успешно

отображается. В противном случае появится сообщение об ошибке.

Вы можете получить больше информации, если воспользуетесь параметром -verbose. Пример использования jarsigner с параметром -verbose показан ниже вместе с образцом вывода:

Подтверждение информации о сертификате

Если вы укажете параметр -certs при проверке вместе с параметрами -verify и -verbose, выходные данные будут включать информацию о сертификате для каждого лица, подписавшего файл JAR, включая тип сертификата, информацию об отличительном имени подписывающего лица (если оно сертификат X.509), а в скобках — псевдоним хранилища ключей для подписавшего, если сертификат открытого ключа в файле JAR совпадает с сертификатом в записи хранилища ключей. Например,

Если сертификат подписывающей стороны не является сертификатом X.509, информация об отличительном имени отсутствует. В этом случае отображаются только тип сертификата и псевдоним. Например, если сертификат является сертификатом PGP, а псевдоним "bob", вы получите

Проверка JAR-файла, включающего подписанты баз данных удостоверений

Если файл JAR был подписан с помощью инструмента JDK 1.1 javakey, и, таким образом, подписывающее лицо является псевдонимом в базе данных удостоверений, выходные данные проверки включают символ "i". Если файл JAR был подписан как псевдонимом в базе данных удостоверений, так и псевдонимом в хранилище ключей, отображаются как "k", так и "i".

При использовании параметра -certs любые псевдонимы базы данных удостоверений отображаются в квадратных скобках, а не в круглых скобках, которые используются для псевдонимов хранилища ключей. Например:

Обратите внимание, что псевдоним "Герцог" заключен в скобки, чтобы указать, что это псевдоним базы данных удостоверений, а не псевдоним хранилища ключей.

Вы используете инструмент jarsigner для подписи и проверки файлов Java Archive (JAR).

Параметры командной строки. См. Параметры для jarsigner.

Опция -verify может принимать ноль или более псевдонимов хранилища ключей после имени файла JAR. Если указан параметр -verify, команда jarsigner проверяет, соответствует ли сертификат, используемый для проверки каждой подписанной записи в файле JAR, одному из псевдонимов хранилища ключей. Псевдонимы определяются в хранилище ключей, указанном параметром -keystore, или в хранилище ключей по умолчанию.

Если вы также укажете параметр -strict и команда jarsigner обнаружит серьезные предупреждения, отобразится сообщение "jar проверено, с ошибками подписанта".

Подписываемый JAR-файл.

Если вы также указали параметр -strict и команда jarsigner обнаружила серьезные предупреждения, отобразится сообщение "jar подписано с ошибками подписанта".

Псевдонимы определяются в хранилище ключей, указанном параметром -keystore, или в хранилище ключей по умолчанию.

У инструмента jarsigner две цели:

Чтобы подписать файлы архива Java (JAR).

Чтобы проверить подписи и целостность подписанных файлов JAR.

Функция JAR позволяет упаковывать файлы курсов, изображения, звуки и другие цифровые данные в один файл для более быстрого и удобного распространения. Инструмент jar позволяет разработчикам создавать файлы JAR.(Технически любой файл ZIP также может считаться файлом JAR, хотя при создании командой jar или обработке командой jarsigner файлы JAR также содержат файл META-INF/MANIFEST.MF.)

Цифровая подпись – это строка битов, которая вычисляется на основе некоторых данных (подписываемых данных) и закрытого ключа объекта (лица, компании и т. д.). Подобно собственноручной подписи, цифровая подпись имеет много полезных характеристик:

Его подлинность можно проверить с помощью вычислений, в которых используется открытый ключ, соответствующий закрытому ключу, используемому для создания подписи.

Его нельзя подделать, если закрытый ключ хранится в секрете.

Это функция подписанных данных, поэтому ее нельзя считать подписью и для других данных.

Подписанные данные изменить нельзя. Если данные изменены, подлинность подписи не может быть проверена.

Чтобы сгенерировать подпись объекта для файла, объект должен сначала иметь связанную с ним пару открытого и закрытого ключей и один или несколько сертификатов, удостоверяющих подлинность его открытого ключа. Сертификат – это заявление с цифровой подписью от одного объекта, в котором говорится, что открытый ключ другого объекта имеет определенное значение.

Команда jarsigner использует информацию о ключе и сертификате из хранилища ключей для создания цифровых подписей для файлов JAR. Хранилище ключей — это база данных закрытых ключей и связанных с ними цепочек сертификатов X.509, которые аутентифицируют соответствующие открытые ключи. Команда keytool используется для создания и администрирования хранилищ ключей.

Команда jarsigner использует закрытый ключ объекта для создания подписи. Подписанный файл JAR содержит, среди прочего, копию сертификата из хранилища ключей для открытого ключа, соответствующего закрытому ключу, использованному для подписи файла. Команда jarsigner может проверить цифровую подпись подписанного файла JAR, используя сертификат внутри него (в его файле блока подписи).

Команда jarsigner может генерировать подписи, содержащие отметку времени, которая позволяет системам или программам развертывания (включая подключаемый модуль Java) проверять, был ли подписан файл JAR, когда сертификат подписи все еще действителен.

Хотя подключаемый модуль Java доступен и поддерживается в JDK 9, он помечен как устаревший в связи с подготовкой к удалению в будущем выпуске. Альтернативы аплетам и встроенным приложениям JavaFX, для которых требуется подключаемый модуль, включают Java Web Start и автономные приложения.

Кроме того, API позволяют приложениям получать информацию о метках времени.

В настоящее время команда jarsigner может подписывать только файлы JAR, созданные с помощью команды jar, или файлы zip. Файлы JAR аналогичны zip-файлам, за исключением того, что они также имеют файл META-INF/MANIFEST.MF. Файл META-INF/MANIFEST.MF создается, когда команда jarsigner подписывает ZIP-файл.

По умолчанию команда jarsigner подписывает JAR- или ZIP-файл. Используйте параметр -verify для проверки подписанного JAR-файла.

Команда jarsigner также пытается проверить сертификат подписывающей стороны после подписания или проверки. В случае ошибки проверки или любой другой проблемы команда генерирует предупреждающие сообщения. Если вы укажете параметр -strict, команда будет рассматривать серьезные предупреждения как ошибки. См. Ошибки и предупреждения.

Все объекты хранилища ключей доступны с уникальными псевдонимами.

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

Хранилища ключей защищены паролем, поэтому необходимо указать пароль хранилища. Вам будет предложено ввести его, если вы не укажете его в командной строке. Точно так же закрытые ключи защищены в хранилище ключей паролем, поэтому пароль закрытого ключа должен быть указан, и вам будет предложено ввести пароль, если вы не укажете его в командной строке, и он не совпадает с хранилищем. пароль.

Команда jarsigner имеет параметр -keystore для указания URL-адреса используемого хранилища ключей. Хранилище ключей по умолчанию хранится в файле с именем .keystore в домашнем каталоге пользователя, что определяется системным свойством user.home.

Oracle Solaris, Linux и OS X: : user.home по умолчанию указывает домашний каталог пользователя.

Входной поток из параметра -keystore передается методу KeyStore.load. Если в качестве URL-адреса указано NONE, то методу KeyStore.load передается нулевой поток. NONE следует указывать, если класс KeyStore не основан на файлах, например, когда он находится на аппаратном токен-устройстве.

Класс KeyStore, предоставляемый в пакете java.security, предоставляет ряд четко определенных интерфейсов для доступа и изменения информации в хранилище ключей. У вас может быть несколько разных конкретных реализаций, каждая из которых предназначена для определенного типа хранилища ключей.

В настоящее время существует два инструмента командной строки, которые используют реализации хранилища ключей ( keytool и jarsigner ). Вы также можете использовать инструмент policytool с графическим интерфейсом, но он устарел и может быть удален в будущем выпуске JDK. . Поскольку класс KeyStore общедоступен, пользователи JDK могут создавать дополнительные приложения безопасности, использующие его.

Реализация хранилища ключей по умолчанию — PKCS12. Это кроссплатформенное хранилище ключей, основанное на стандарте синтаксиса обмена личной информацией RSA PKCS12. Этот стандарт в первую очередь предназначен для хранения или транспортировки закрытых ключей пользователя, сертификатов и различных секретов. Существует еще одна встроенная реализация, предоставленная Oracle. Он реализует хранилище ключей в виде файла с проприетарным типом (форматом) хранилища ключей с именем JKS. Он защищает каждый закрытый ключ своим индивидуальным паролем, а также защищает целостность всего хранилища ключей с помощью (возможно, другого) пароля.

Реализации хранилища ключей основаны на поставщиках, что означает, что интерфейсы приложений, предоставляемые классом хранилища ключей, реализуются с точки зрения интерфейса поставщика услуг (SPI). Существует соответствующий абстрактный класс KeystoreSpi, также в пакете java.security, который определяет методы интерфейса поставщика услуг, которые должны реализовать поставщики. Термин «поставщик» относится к пакету или набору пакетов, которые предоставляют конкретную реализацию подмножества сервисов, к которым может обращаться Java Security API. Чтобы обеспечить реализацию хранилища ключей, клиенты должны реализовать поставщика и предоставить реализацию подкласса KeystoreSpi, как описано в разделе «Как реализовать поставщика в архитектуре криптографии Java».

Приложения могут выбирать различные типы реализации хранилища ключей от разных поставщиков с помощью фабричного метода getInstance в классе KeyStore. Тип хранилища ключей определяет способ хранения и формат данных информации хранилища ключей, а также алгоритмы, используемые для защиты закрытых ключей в хранилище ключей и целостность самого хранилища ключей. Реализации хранилища ключей разных типов несовместимы.

Команды jarsigner и policytool могут считывать файловые хранилища ключей из любого места, которое можно указать с помощью URL-адреса. Кроме того, эти команды могут считывать нефайловые хранилища ключей, например те, что предоставляются MSCAPI в Windows и PKCS11 на всех платформах.

Для команд jarsigner и keytool можно указать тип хранилища ключей в командной строке с параметром -storetype. Для Инструмента политики вы можете указать тип хранилища ключей с помощью команды «Редактировать» в меню «Хранилище ключей».

Если вы явно не укажете тип хранилища ключей, инструменты выберут реализацию хранилища ключей на основе значения свойства keystore.type, указанного в файле свойств безопасности. Файл свойств безопасности называется java.security и находится в каталоге свойств безопасности JDK, java.home/conf/security .

Каждый инструмент получает значение keystore.type, а затем проверяет все установленные поставщики, пока не найдет тот, который реализует хранилища ключей этого типа. Затем он использует реализацию хранилища ключей от этого поставщика.

Класс KeyStore определяет статический метод с именем getDefaultType, который позволяет приложениям и аплетам извлекать значение свойства keystore.type. Следующая строка кода создает экземпляр типа хранилища ключей по умолчанию, как указано в свойстве keystore.type:

Тип хранилища ключей по умолчанию — pkcs12 . Это кроссплатформенное хранилище ключей, основанное на стандарте синтаксиса обмена личной информацией RSA PKCS12. Это указывается следующей строкой в файле свойств безопасности:

Регистр не имеет значения в обозначениях типов хранилища ключей. Например, JKS — это то же самое, что и jks .

Чтобы инструменты использовали реализацию хранилища ключей, отличную от используемой по умолчанию, вы можете изменить эту строку, указав другой тип хранилища ключей. Например, если вы хотите использовать реализацию хранилища ключей Oracle jks, измените строку на следующую:

По умолчанию команда jarsigner подписывает файл JAR, используя один из следующих файлов алгоритмов в зависимости от типа и размера закрытого ключа:

Java и JVM (виртуальная машина Java) широко используются и требуются для многих типов программного обеспечения. Эта статья проведет вас через процесс установки и управления различными версиями Java с помощью apt-get .

Предпосылки

Чтобы следовать этому руководству, вам потребуется:

Один сервер Ubuntu 16.04.

Пользователь sudo без полномочий root, которого можно настроить, следуя руководству по первоначальной настройке сервера Ubuntu 16.04.

Установка JRE/JDK по умолчанию

Самый простой способ установки Java – использовать версию, поставляемую вместе с Ubuntu. В частности, будет установлена последняя и рекомендуемая версия OpenJDK 8.

Сначала обновите индекс пакета.

Далее установите Java. В частности, эта команда установит среду выполнения Java (JRE).

Есть еще одна установка Java по умолчанию, которая называется JDK (Java Development Kit). JDK обычно требуется только в том случае, если вы собираетесь компилировать Java-программы или если это требуется программному обеспечению, которое будет использовать Java.

JDK содержит JRE, поэтому при установке JDK вместо JRE нет никаких недостатков, за исключением большего размера файла.

Вы можете установить JDK с помощью следующей команды:

Установка Oracle JDK

Если вы хотите установить Oracle JDK, официальную версию, распространяемую Oracle, вам потребуется выполнить еще несколько шагов.

Сначала добавьте Oracle PPA, а затем обновите репозиторий пакетов.

Затем, в зависимости от версии, которую вы хотите установить, выполните одну из следующих команд:

Oracle JDK 8

Это последняя стабильная версия Java на момент написания статьи и рекомендуемая версия для установки. Вы можете сделать это с помощью следующей команды:

Oracle JDK 9

Это предварительная версия для разработчиков, а общий выпуск запланирован на март 2017 года. Не рекомендуется использовать эту версию, так как в ней все еще могут быть проблемы с безопасностью и ошибки. Дополнительную информацию о Java 9 можно найти на официальном веб-сайте JDK 9.

Чтобы установить JDK 9, используйте следующую команду:

Управление Java

На одном сервере может быть несколько установок Java. Вы можете настроить версию по умолчанию для использования в командной строке с помощью update-alternatives , который определяет, какие символические ссылки используются для разных команд.

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

Теперь вы можете выбрать номер, который будет использоваться по умолчанию. Это также можно сделать для других команд Java, таких как компилятор ( javac ), генератор документации ( javadoc ), средство подписи JAR ( jarsigner ) и многое другое. Вы можете использовать следующую команду, заполнив команду, которую хотите настроить.

Настройка переменной среды JAVA_HOME

Многие программы, например серверы Java, используют переменную среды JAVA_HOME для определения места установки Java. Чтобы установить эту переменную среды, нам сначала нужно выяснить, где установлена Java. Вы можете сделать это, выполнив ту же команду, что и в предыдущем разделе:

Скопируйте путь из предпочтительной установки, а затем откройте /etc/environment с помощью nano или вашего любимого текстового редактора.

В конце этого файла добавьте следующую строку, заменив выделенный путь собственным скопированным путем.

Сохраните и закройте файл, а затем перезагрузите его.

Теперь вы можете проверить, установлена ли переменная среды, выполнив следующую команду:

Это вернет путь, который вы только что установили.

Заключение

Теперь вы установили Java и знаете, как управлять различными ее версиями. Теперь вы можете устанавливать программное обеспечение, работающее на Java, например Tomcat, Jetty, Glassfish, Cassandra или Jenkins.

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

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

Читайте также: