Форматы файлов для хранения ключей/сертификатов

И так повторим теорию шифрования открытыми ключами:
Генерируется приватный ключ, который хранится в защищенном месте, на основе его генерируется публичный ключ, который предоставляется тем, кто хочет передавать сообщения автору и быть уверенным в том, что никто не сможет его прочитать кроме автора. Все что закодировано публичным ключем, может быть раскодированно только приватным.
Чтобы пользователь публичного ключа был действительно уверенным, что у него оказался ключ не злоумышленника, придумали сертификаты открытых ключей. Суть в том, что третье лицо "аля власть в сертификации открытыми ключами" CA под каждый публичный ключ вставляет свою цифровую подпись, которая имеет ограниченное время жизни, и его ответсвенность в том, чтобы гарантировать, что тот кто представляется собой в сертификате, действительно яляется собою и публичный ключ, которых хранится в этом сертификате действительно его.
Формат файла для сертификата и процедуру распределения открытых ключей с помошью сертификатов с цифровыми подписями определяется стандартом X.509.
Формат файла сертификата по стандарту X.509:

• Номер версии(текущая 3)
• Серийный номер
• Эмитент
• Субъект
• Открытый ключ субъекта (алгоритм, ключ)
• Период действия
• Дополнительные (необязательные) значения
• Алгоритм подписи сертификата
• Значение подписи сертификата

(*.p12) Personal Information Exchange (PKCS #12)

Файл, который является безопасным(кодирование + пароль на розархивирование/чтение) хранилищем(архивом) для приватных ключей, сертификатов,  и цепочек сертификатов.

Это единственный формат, который может быть использован для експортирования сертификата и его приватного ключа в java keystore(jks)/truststore(jts).

(*.p7b) Cryptographic Message Syntax Standard (PKCS #7)

Используется как хранилище для цепочек сертификатов.

(*.cer | *.der) DER-encoded binary X.509

Формат хранилища сертификатов в бинарном виде, который является стандартом для Internet. Он не для приватных ключей, ни для цепочек.
(*.der) Distinguished Encoding Rules

(*.cer | *.pem) Base64-encoded X.509

Используется для тех же целей, что и предыдущий, но способ хранения данных в файле отличается (похоже занимает больше места на диске, потому что не бинарный а текстовый).
(*.pem) Privacy Enhanced Email
Файл в котором хранятся ключи/сертификаты в обычном текстовом формате. Его конек в том, что данные могут оттуда и туда копироваться как в обычный текстовый файл через GUI операционных систем. Только вот нужно следить чтобы в отметках начала и конца(-----BEGIN ENCRYPTED PRIVATE KEY----- и -----END ENCRYPTED PRIVATE KEY-----) не терять "минусы". И если мы это делали в Windows, то в файле нужно будет поудалять возрврат каретки. Тоесть в файл можно позгружать и всю цепочку сертификатов, ключи и приватные и публичные, но обычно так никто не делает, их разбивают на отдельные файлы, особенно приватный ключ находится в отдельном файле.

(*.crt) альтернативное имя расширения *.cer, как для бинарного, так и аски-формата,  этот вариант более характерен для *nix мира, а cer соответсвует Microsoft Convention.

(*.csr) Certificate Signing Request
Файл, в который генерируется на основе [только что созданного] приватного ключа публичный ключ и добавляется информации о авторе этого сертификата. В файле оказывается только что сгенерированный публичный ключ автора и информация о нем. Этот файл отправляется на подпись к certificate-authorities(CA), который своей подписью под сертификатом гарантирует, что автор является действительно тем, кем представляется в сертификате, CA из этого файла генерирует сертификат в формате X.509.


(*.key) PKCS#8

Чеще всего в таком файле хранятся приватные ключи. Но также могут храниться и публичные.  Закодированы они могут быть как в формате pem, так и der.

Существует 4 основых манипуляции над сертификатами:
- Просмотр.
- Преобразование.
- Соединение.
- Извлечение.

Чтобы просмотеть содержимое сертификата будь то der или pem, оба нужно декодировать в человекочитаемый вид.
Прочитать PEM:

openssl x509 -in cert.pem -text -noout
openssl x509 -in cert.cer -text -noout
openssl x509 -in cert.crt -text -noout

Прочитать DER:

openssl x509 -in certificate.der -inform der -text -noout

Чтобы преобразовать один формат в другой мы используем команды.
PEM to DER:

openssl x509 -in cert.crt -outform der -out cert.der

DER to PEM:

openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

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

Извлечение
Нам прислали файл с цепочкой и ключами, но нам нужет только ключ, если обьединили PEMы, то тогда это просто: открыли, нашли по коментариям-отметкам и скопировали только то, что нам нужно.

Как проверить сертификат, который в jks

Нужно его импортировать в формат, в котором его принимает браузер, и отсправить эту генерацию вместе с запросом curl к ресурсу.
Для этого нам нужно:
1) Ипортировать сертификат в формат pkcs12 из jks.
2) Трансформировать pkcs12 в pem
3) Попытаться получить по curl ответ с сервера с полученным сертификатом.

$ keytool -importkeystore -srckeystore foo.jks \
   -destkeystore foo.p12 \
   -srcalias foo \
   -srcstoretype jks \
   -deststoretype pkcs12

$ openssl pkcs12 -in foo.p12 -out foo.pem

$ curl --cert foo.pem:password https://www.example.com/some_protected_page

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

$ keytool -keystore foo.jks -exportcert -alias foo | \
   openssl x509 -inform der -text

$ openssl x509 -text -in foo.pem

Есть еще вызов, только что это за формат не понятно, нужно разбираться:

$ openssl dsa -text -in foo.pem

Открыть порт в линукс файерволе

$ iptables -A INPUT -p tcp --dport 25 -j ACCEPT
$ iptables -I OUTPUT -p tcp --dport 25 -j ACCEPT
$ service iptables save
$ service iptables restart

Основные комманды keytool

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

Проперти JVM, которые используются для информации о ключах:

javax.net.ssl.keyStore
javax.net.ssl.keyStorePassword

javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword

Не факт, но вроде как кисторы с расширением .pem(вроде как кодировка здесь rsa) используются openssl, p12 - всяким другим в том числе и JSSE

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

keytool -list -keystore path/to/my.keystore

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

keytool -list -keystore path/to/my.keystore -v

Импортировать ключи&сертификаты, которые соединены в формат PKCS12:

keytool -importkeystore 
        -destkeystore my.keystore -destalias myalias_in_mykeystore
        -srckeystore someout.p12 -srcstoretype PKCS12 -srcalias their_alias

Если пароль ключа из p12 будет отличается от пароля jks( джава кистора ), то такой сертификат не будет работать, поэтому, поэтому пароль нужно сменить при импорте, делается это вот так:

keytool -importkeystore 
        -destkeystore my.keystore -destalias myalias_in_mykeystore
        -srckeystore someout.p12 -srcstoretype PKCS12 -srcalias their_alias
keytool -importkeystore 
        -srckeystore their.p12 -srcalias their_alias 
        -destkeystore my.jks -destalias my_alias -srcstoretype PKCS12 -destkeypass MY_JKS_PASS_FOR_NEW_KEY

Дальще мы введем пароль нашего хранилища и хранилища p12 и готово.

 Преобразовать сертификат и ключ к нему в один файл формата pkcs12:

openssl pkcs12 -export 
               -in certificate.cer -inkey the_key.key 
               -out combined_result.p12 -name my_alias -CAfile this_file_is_never_generate.crt

Удалить сертификат и ключ по алиасу:

keytool -delete -alias delete_me -keystore my.jks

Добавить серификаты удаленного сервера в наш трастстор:

keytool -import -file SOMECER.CER -alias NAME_FOR_OUR_STORE -keystore MYKEYSTORE.JKS –storepass CHANGING_TO_BE_THE_SAME_AS_FOR_KEYSTORE

Иногда бывает нужно переименовать алиас в кисторе:

keytool -changealias -alias OLD_ALIAS -destalias NEW_ALIAS -keystore MYKEYSTORE.jks

Добабить удаленный репозиторий и в одном месте залить туда бранч, в другом - слить

Добавить и залить:

git remote add github https://github.com/user/repo.git
git push -u github my-release

А в другом месте добаить и взять залитое:

git remote add github https://github.com/user/repo.git
git fetch github

git checkout -b my-release github/my-release

Теперь мы отдельно можем работать либо с ORIGIN либо с GITHUB ремоутом.

Интсрукция настройки репликации на mysql

1) master my.cnf(my.ini )

[mysqld]
log-bin=mysql-bin
server-id=1

innodb_flush_log_at_trx_commit=1
sync_binlog=1

# skip-networking
# bind-address          = 127.0.0.1 # разрешаем конектиться не только с локального хоста

service mysql restart

2) slave my.cnf(my.ini ):

[mysqld]
server-id=2