Может ли Windows 7 Профессиональный OEM-производитель может быть создан с помощью WDS?
Каждый год я обнаруживаю, что устанавливаю Windows 7 десятки раз, как на совершенно новые ПК, так и перед передачей бывшего в употреблении ПК от одного пользователя другому. Я уверен, что МНОЖЕСТВО сетевых администраторов находится в одной лодке.
Обновления Windows занимают ДЛИННОЕ время, и это сэкономит так много времени, имея возможность создать образ, обновленный со всеми обновлениями Windows, и развернуть его с помощью Windows Службы развертывания (WDS).
После установки OEM-образа Dell на виртуальную машину, его обновления, создания моментального снимка, запуска sysprep generalize, захвата образа в WDS и развертывания этого образа на физическом компьютере Dell OptiPlex у меня возникли проблемы с активацией OEM-ключа с наклейки COA. онлайн, и пришлось позвонить для ручной активации ... которая прошла нормально, но была болезненным процессом прослушивания автоматизированной системы и ввода множества цифр.
- Было ли это просто счастливой случайностью? Должен ли этот сценарий нормально работать без необходимости звонка по телефону для активации вручную?
- Можно ли использовать OEM-носители для создания образов, или мне нужно использовать носители с корпоративной лицензией? А при использовании носителя с корпоративной лицензией мне нужно вводить OEM-ключ, указанный на наклейке COA?
- Двигаясь вперед, OEM-производители, такие как Dell, встраивают ключи в UEFI BIOS на новых ПК,
Сертификат rootCA.crt должен быть импортирован в доверенные центры в браузере или почтовом клиенте.
Якобы сертификат rootCA.crt должен быть импортирован в доверенные центры в браузере или почтовом клиенте. Это тоже странное путешествие:
rootCA import
sudo cp rootCA.crt /etc/ssl/certs/worldDomCA.crt #symlink named after its hash.4, hash result is same after rename so I used the local version rather than the renamed etc/ssl version sudo ln -s /etc/ssl/certs/worldDomCA.crt /etc/ssl/certs/'openssl x509 -hash -noout -in rootCA.crt'.4 #this just hangs, disturbingly openssl verify -CApath /etc/ssl/certs/worldDomCA.crtПо общему признанию, я не уверен, куда даже поместить файлы сертификатов CAchain и сервера, но, что более важно, s_client жалуется, что сертификат все еще самоподписан, а не просто висит вроде проверю. Судя по строкам субъекта и эмитента
subject=/C=US/ST=test/L=test/O=test/OU=test/CN=servername.domain.int issuer=/C=US/ST=test/L=test/O=test/OU=test/CN=servername.domain.int, сертификаты включают DN коробки, на которой они были подделаны. Могу ли я уйти от этого, если я создал свои центры сертификации на другом компьютере, а затем принес его и использовал для подписания сертификатов сервера / клиента? Примечательно, что оба сервера работают на одном компьютере, поскольку вся эта неразбериха все еще находится на стадии исследовательской оценки.
Ну, оказывается, что ответ - "Да, но не нужно". Большая часть этого поколения PKI там просто отлично, хотя не все эти файлы на самом деле используются - файлы CAchain на самом деле не нужны для верификации, так как openssl верификация принимает только два аргумента, клиентские файлы не нужны, а srl файлы являются побочными продуктами. Проблема заключается в том, что выдается CN, соответствующий запрашиваемому CN, так как клиенты проверяют сертификаты по доменам.
Чтобы заставить Tomcat представить сертификат PKI, а не самоподписанный сертификат, многие руководства рекомендуют запустить HTTPS, есть два дополнительных шага:
преобразовать в pkcs12
openssl pkcs12 -export -chain -passout pass:butts -in server.crt -inkey server.key -out server.p12 -name alias -CAfile (intermediateCA.crt or CAchain.crt) -caname steeve
затем импортировать в клавиатуру Tomcat'sJKS
..... Убедитесь, что новая запись соответствует тому, что ищет конфигурация tomcat, и изменение псевдонима оригинального первого
keytool -changealias -alias tomcat -destalias derpcat -storepass changeit
keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore server.keystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass butts -alias tomcat
storepass и клавиатуры должно совпасть, чтобы это сработало.
s_client до сих пор пишет о том, что rootCA является самоподписанным, и клиент должен установить rootCA (я не могу винить их в том, что они не доверяют "World Domination"), но CAS redirect SSO теперь работает без проблем.
. Чтобы проверить вашу цепочку, вам нужно добавить якорь доверия в список OpenSSL. Это состоит из размещения вашего корневого сертификата CA в известном месте и выполнения команды update-ca-trust .
В моей системе Fedora каталог - / etc / pki / ca-trust / источник / якоря . Запуск update-ca-trust добавляет сертификат к /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt . В разных дистрибутивах используются разные пути, поэтому здесь может потребоваться некоторое исследование.
Чтобы проверить путь, выполните:
$ openssl verify -CApath /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt -untrusted intermediateCA.crt server.crt
server.crt: OK
Опять же, путь к -CApath может быть другим на вашем компьютере.
openssl s_client проверяет сертификаты как клиент SSL / TLS. Поэтому вы указываете его на URL-адрес удаленного сервера. Перед этим вам необходимо установить и подчиненный сертификат CA, и сертификат конечного объекта (сервера) и закрытый ключ на этом удаленном компьютере. Этот процесс, конечно, зависит от того, какое приложение вы используете для своего удаленного сервера. Например, с apache вы помещаете файлы в разумное место и указываете на них в конфигурации вашего сайта с помощью:
SSLEngine on
SSLCertificateFile /etc/pki/tls/certs/server.crt
SSLCertificateKeyFile /etc/pki/tls/private/server.key
SSLCertificateChainFile /etc/pki/tls/certs/world-domination.ca-bundle
(обратите внимание, что SSLCertificateChainFile устарел, начиная с версии 2.4.8. )
Похоже, что полученные вами выходные данные предполагают, что сертификаты, установленные в настоящее время на этом удаленном компьютере, являются самозаверяющими, созданными во время установки.