Преобразование из самоподписанного в коммерческий сертификат TLS ошибок - PullRequest
1 голос
/ 07 мая 2019

Когда я установил наш кластер, я использовал самоподписанный сертификат нашего внутреннего центра сертификации. Все было хорошо, пока я не начал получать сертификаты об ошибках от приложений, которые я развертывал в кластере OKD. Мы решили вместо того, чтобы пытаться исправить ошибки по одному за все время, мы просто купили бы коммерческий сертификат и установили его. Поэтому мы купили сертификат SAN с подстановочными знаками (идентичными тому, который мы изначально получили от нашего внутреннего ЦС) от GlobalSign, и я пытаюсь установить его с огромными проблемами.

Имейте в виду, я пробовал десятки итераций здесь. Я просто документирую последний, который я попробовал, чтобы выяснить, в чем проблема. Это на моем тестовом кластере, который является сервером VM, и я возвращаюсь к снимку после каждого. Снимок - это операционный кластер, использующий внутренние сертификаты CA.

Итак, моим первым шагом было создание моего CA-файла, который нужно передать. Я загрузил корневые и промежуточные сертификаты для GlobalSign и поместил их в файл ca-globalsign.crt. (В формате PEM)

когда я бегу

openssl verify -CAfile ../ca-globalsign.crt labtest.mycompany.com.pem

я получаю:

labtest.mycompany.com.pem: OK

и openssl x509 -in labtest.mycompany.com.pem -text -noout дает мне (отредактировано)

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            (redacted)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
        Validity
            Not Before: Apr 29 16:11:07 2019 GMT
            Not After : Apr 29 16:11:07 2020 GMT
        Subject: C=US, ST=(redacted), L=(redacted), OU=Information Technology, O=(redacted), CN=labtest.mycompany.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    (redacted)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            Authority Information Access:
                CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
                OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.4146.1.20
                  CPS: https://www.globalsign.com/repository/
                Policy: 2.23.140.1.2.2

            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:labtest.mycompany.com, DNS:*.labtest.mycompany.com, DNS:*.apps.labtest.mycompany.com
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                (redacted)
            X509v3 Authority Key Identifier:
                (redacted)

            (redacted)

на моей локальной машине. Все, что я знаю о SSL, говорит, что сертификат в порядке. Эти новые файлы помещаются в проект, который я использую для хранения конфигов, и для моей установки OKD.

Затем я обновил файлы сертификатов в своем проекте инвентаризации и выполнил команду

ansible-playbook -i ../okd_install/inventory/okd_labtest_inventory.yml playbooks/redeploy-certificates.yml

Когда я читаю документы, все говорят мне, что он должен просто пройти через процесс и придумать новые сертификаты. Этого не происходит Когда я использую openshift_master_overwrite_named_certificates: false в моем файле инвентаризации, установка завершается, но она заменяет только сертификат в домене *.apps.labtest, но console.labtest остается оригиналом, но он подключается, за исключением того факта, что мониторинг говорит bad gateway в консоли кластера.

Теперь, если я попытаюсь запустить команду еще раз, при использовании openshift_master_overwrite_named_certificates: true мой /var/log/containers/master-api*.log будет залит такими ошибками, как эта

{"log":"I0507 15:53:28.451851       1 logs.go:49] http: TLS handshake error from 10.128.0.56:46796: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.451894391Z"}
{"log":"I0507 15:53:28.455218       1 logs.go:49] http: TLS handshake error from 10.128.0.56:46798: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.455272658Z"}
{"log":"I0507 15:53:28.458742       1 logs.go:49] http: TLS handshake error from 10.128.0.56:46800: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.461070768Z"}
{"log":"I0507 15:53:28.462093       1 logs.go:49] http: TLS handshake error from 10.128.0.56:46802: EOF\n","stream":"stderr","time":"2019-05-07T19:53:28.463719816Z"}

и эти

{"log":"I0507 15:53:29.355463       1 logs.go:49] http: TLS handshake error from 10.70.25.131:44424: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.357218793Z"}
{"log":"I0507 15:53:29.357961       1 logs.go:49] http: TLS handshake error from 10.70.25.132:43128: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.358779155Z"}
{"log":"I0507 15:53:29.357993       1 logs.go:49] http: TLS handshake error from 10.70.25.132:43126: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.358790397Z"}
{"log":"I0507 15:53:29.405532       1 logs.go:49] http: TLS handshake error from 10.70.25.131:44428: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53:29.406873158Z"}
{"log":"I0507 15:53:29.527221       1 logs.go:49] http: TLS handshake error from 10.70.25.132:43130: remote error: tls: bad certificate\n","stream":"stderr","time":"2019-05-07T19:53

и установка зависает на задании ANLS TASK [Remove web console pods]. Он будет сидеть там часами. Когда войдите в консоль мастера и запустите oc get pods на openshift-web-console, он находится в состоянии terminating. Когда я описываю модуль, который пытается начать с pending, он возвращается, говоря, что жесткий диск заполнен. Я предполагаю, что это потому, что он не способен обмениваться данными с системой хранения из-за всех этих ошибок TLS выше. Это просто остается там. Я могу вернуть кластер обратно, если я принудительно удаляю завершающий модуль, затем перезагружаю мастер, затем удаляю новый модуль, который пытается запустить, затем перезагружаюсь во второй раз. Затем веб-консоль подключается к сети, но все мои файлы журналов заполняются этими ошибками TLS. Но более тревожным является то, что установка зависает в этом месте, поэтому я предполагаю, что после подключения веб-консоли есть дополнительные шаги, которые также вызывают у меня проблемы.

Итак, я также попытался повторно развернуть сервер CA. Это привело к проблемам, потому что мой новый сертификат не является сертификатом CA. Затем, когда я только что запустил книгу повторного развертывания CA, чтобы кластер воссоздал серверные CA, все закончилось нормально, но когда я попытался запустить redeploy-certificates.yml, я получил те же результаты.

вот мой файл инвентаря

all:
  children:
    etcd:
      hosts:
        okdmastertest.labtest.mycompany.com:
    masters:
      hosts:
        okdmastertest.labtest.mycompany.com:
    nodes:
      hosts:
        okdmastertest.labtest.mycompany.com:
          openshift_node_group_name: node-config-master-infra
        okdnodetest1.labtest.mycompany.com:
          openshift_node_group_name: node-config-compute
          openshift_schedulable: True
    OSEv3:
      children:
        etcd:
        masters:
        nodes:
        # https://docs.okd.io/latest/install_config/persistent_storage/persistent_storage_glusterfs.html#overview-containerized-glusterfs
        # https://github.com/openshift/openshift-ansible/tree/master/playbooks/openshift-glusterfs
        # glusterfs:
      vars:
        openshift_deployment_type: origin
        ansible_user: root

        openshift_master_cluster_method: native
        openshift_master_default_subdomain: apps.labtest.mycompany.com
        openshift_install_examples: true

        openshift_master_cluster_hostname: console.labtest.mycompany.com
        openshift_master_cluster_public_hostname: console.labtest.mycompany.com
        openshift_hosted_registry_routehost: registry.apps.labtest.mycompany.com

        openshift_certificate_expiry_warning_days: 30
        openshift_certificate_expiry_fail_on_warn: false
        openshift_master_overwrite_named_certificates: true
        openshift_hosted_registry_routetermination: reencrypt

        openshift_master_named_certificates:
          - certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
            keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
            cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"
            names:
              - "console.labtest.mycompany.com"
              # - "labtest.mycompany.com"
              # - "*.labtest.mycompany.com"
              # - "*.apps.labtest.mycompany.com"
        openshift_hosted_router_certificate:
          certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
          keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
          cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"
        openshift_hosted_registry_routecertificates:
          certfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.pem"
          keyfile: "/Users/me/code/devops/okd_install/certs/labtest/commercial.04.29.2019.labtest.mycompany.com.key"
          cafile: "/Users/me/code/devops/okd_install/certs/ca-globalsign.crt"

        # LDAP auth
        openshift_master_identity_providers:
        - name: 'mycompany_ldap_provider'
          challenge: true
          login: true
          kind: LDAPPasswordIdentityProvider
          attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - sAMAccountName
          bindDN: 'ldapbind@int.mycompany.com'
          bindPassword: (redacted) 
          insecure: true
          url: 'ldap://dc-pa1.int.mycompany.com/ou=mycompany,dc=int,dc=mycompany,dc=com'

что мне здесь не хватает? Я думал, что этот redeploy-certificates.yml playbook был разработан, чтобы обновить сертификаты. Почему я не могу передать это моему новому коммерческому сертификату? Это почти как замена сертификатов на маршрутизаторе (вроде), но в процессе завинчивание сертификата внутреннего сервера. Я на самом деле здесь, в конце концов, я не знаю, что еще попробовать.

1 Ответ

3 голосов
/ 08 мая 2019

Вы должны настроить openshift_master_cluster_hostname и openshift_master_cluster_public_hostname как разные имена хостов друг для друга. Оба имени хоста также должны быть разрешены DNS. Ваши коммерческие сертификаты используются в качестве внешней точки доступа.

The openshift_master_cluster_public_hostname and openshift_master_cluster_hostname parameters in the Ansible inventory file, by default /etc/ansible/hosts, must be different. 
If they are the same, the named certificates will fail and you will need to re-install them.

# Native HA with External LB VIPs
openshift_master_cluster_hostname=internal.paas.example.com
openshift_master_cluster_public_hostname=external.paas.example.com

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

Подробнее см. Настройка пользовательских сертификатов . Я надеюсь, что это поможет вам.

...