Сертификат связывает личность с открытым ключом.
Предположим, вы получили от меня электронное письмо с цифровой подписью. Если вы проверяете подпись с открытым ключом, которым вы владеете, то, если вы уверены, что люди хранят закрытые ключи в секрете, вы знаете, что электронное письмо пришло от того, кто имел закрытый ключ, соответствующий этому открытому ключу.
Если вы точно знаете, что у вас есть открытый ключ (например, потому что я вручил его лично вам), то это все, что вам нужно знать. Проблема в том, что ты не всегда это знаешь. Любой может создать пару ключей и отправить открытый ключ по всему Интернету, ложно утверждая, что я, или настроить веб-сервер, ложно утверждающий, что это StackOverflow, или что-то еще. Вы можете узнать номер телефона Google из независимого источника и позвонить им, чтобы подтвердить, что вы получили правильный ключ, но если бы вам приходилось делать это каждый раз, когда вы хотели создать безопасное соединение TLS, тогда электронная коммерция была бы значительно более эффективной. неэффективно, чем сейчас.
Одним из решений является получение сертификата. Он содержит открытый ключ и идентификационную информацию (например, имя и адрес, доменное имя, адрес электронной почты), которая имеет цифровую подпись центра сертификации. Если вы проверяете подпись в сертификате с помощью открытого ключа центра сертификации, то вы знаете, что кто-то, у кого есть доступ к закрытому ключу центра сертификации, был рад подписать сертификат, заявив, что он согласен с тем, что эта идентичность совпадает с этим открытым ключом. Если вы уверены, что центр сертификации не должен этого делать, если он не предпринял разумных шагов для проверки того, что это правда (например, убедившись, что они видят документы, удостоверяющие личность человека, и убедившись, что у этого лица есть закрытый ключ, соответствующий открытому ключу, который появится в сертификате), тогда вы можете быть уверены, что у вас есть правильный ключ для нужного человека.
Но даже если у вас есть это доверие, это только подталкивает проблему на один шаг вверх по цепочке, потому что для проверки сертификата в подписи с открытым ключом центра сертификации вы должны сначала убедиться, что у вас есть правильный открытый ключ для этого центра сертификации. Таким образом, вы можете получить сертификат для этого центра сертификации и обнаружить, что он был выдан другим центром сертификации и т. Д.
Вы, очевидно, не можете проверить бесконечную цепочку сертификатов, поэтому в какой-то момент все это должно прекратиться. В конце концов вы должны проверить, что у вас есть правильный открытый ключ для центра сертификации верхнего уровня, не полагаясь на другой сертификат для этого, и это ваш якорь доверия.
Итак, предположим, у вас есть сертификат для меня, и вы видите, что он подписан центром сертификации ABC, центром сертификации, о котором вы никогда не слышали. Вы получаете сертификат для ABC и используете в нем открытый ключ для проверки подписи на моем сертификате, и это доказывает, что центр сертификации ABC действительно выдал мой сертификат.
Затем вы смотрите на сертификат ABC Certificate Authority и видите, что он подписан DEF Certificate Authority, центром сертификации, которому вы доверяете и для которого у вас уже есть самозаверяющий сертификат или якорь доверия. Вы используете открытый ключ в сертификате DEF для проверки подписи в сертификате ABC, и это доказывает, что DEF действительно выдал этот сертификат для ABC.
Чтобы быть уверенным в том, что мой сертификат действителен, вам необходимо сделать несколько вещей и сделать несколько предположений:
Вам необходимо получить и доверять (самоподписанному) сертификату для центра сертификации DEF, который является вашим якорем доверия. В большинстве случаев ваш браузер и / или операционная система будут предварительно загружены целым рядом сертификатов CA, которым производитель решил доверять, и вы просто слепо доверяете суждению производителя по этому поводу, но вы можете сделать свои собственные шаги, чтобы подтвердите это, если хотите.
Вы должны быть уверены, что DEF является законным и заслуживающим доверия центром сертификации, который будет защищать свой закрытый ключ и не будет выдавать сертификаты кому-либо, если у него нет веских причин для этого. Опять же, вы, скорее всего, будете доверять производителю в этом, но большинство ЦС регулярно проверяют свои процессы и сертификаты выдачи сертификатов, поэтому, если вы обеспокоены, вы можете получить последний аудиторский отчет для этого конкретного ЦС, например , Обратите внимание, что для этого необходимо, чтобы вы доверяли суждению одитора, и в зависимости от того, каким путем вы идете, в какой-то момент вам нужно доверять кому-то только потому, что он заслуживает доверия.
Вы должны быть уверены, что DEF не выдаст промежуточный сертификат CA в центр сертификации ABC, если у него нет веских оснований полагать, что ABC также является законным и заслуживающим доверия центром сертификации, который будет обеспечивать безопасность своего закрытого ключа. и не выдавать сертификаты без уважительной причины. Здесь вы не доверяете ABC напрямую - вы доверяете ей, потому что DEF доверяет ей, и вы доверяете DEF.
Эта же логика применяется, если в цепочке между доверенным якорем и сертификатом конечного пользователя имеется более одного промежуточного сертификата ЦС - вы фактически доверяете каждому промежуточному ЦС в цепочке на том основании, что предыдущий ЦС в цепь не выдала бы им свой сертификат CA, если бы не убедилась, что они являются надежным CA, и если бы она не подтвердила, что открытый ключ в промежуточном сертификате CA действительно принадлежит этому промежуточному CA. Проверяя подпись в каждом промежуточном сертификате CA с открытым ключом CA непосредственно перед ним в цепочке, вы демонстрируете, что предыдущий CA действительно выдал этот сертификат. Поскольку вы явно доверяете корневому центру сертификации, то если ваш якорь доверия находится в нижней части этой цепочки, вы создали неявную цепочку доверия, которая дает вам уверенность в том, что сертификат конечного пользователя, который вас изначально интересовал, хорош .
В конечном счете все это основано на идее, что вы просто явно доверяете горстке хорошо известных корневых ЦС, и тогда вы можете неявно доверять любой из миллиардов других удостоверений в Интернете, если сможете найти цепочку действительных сертификатов. вернуться к одному из тех корней, которым вы явно доверяете, и если вы готовы принять идею о том, что каждый промежуточный ЦС в этой цепочке заслуживает доверия на этом основании.
Реальность такова, что центры сертификации обычно очень внимательно относятся к выдаче промежуточных сертификатов CA, и при выдаче их сторонним организациям часто ограничивают их, так что промежуточный сертификат CA, выданный ACME Inc, может использоваться только для выдачи сертификатов для ACME. Inc сотрудников, или выдавать сертификаты только для доменов, которые заканчиваются на .acme.com, например.