現在インターネットにおいては電子商取引が活発に行われており、即時注文決済を行うバーチャルショップも登場している。消費者であるユーザ側では、インターネットがオープンな場であることの認知度が高まり「インターネットは危険」という意識も広まりつつある。 　ユーザのこれらの不安を解消するためにモールではあらゆる方法でセキュリティを確保していることを宣言してユーザの安心感を得ている。実際には暗号技術を駆使することで実現されるが、ユーザからはブラックボックス化されているためどのくらい安全なのかについての尺度を持つことはできないかもしれない。 　これまでに紹介した SSL や S/MIME などのセキュリティプロトコルだけでなく SET (Secure Electronic Transaction) などの電子決済に特化したプロトコルも提案されており、安全な商取引を可能にする仕組みは提供され整備されつつある。 　SSL, S/MIME 及び SET といったプロトコルの安全性の根拠となる大前提として、認証局を信用する必要がある。 　InternetExplorer や NetscapeCommunicator ではこの信用の基点となる認証局の証明書がいくつか組み込まれており、デフォルトで信用するというフラグをつけて配布されている。ユーザ側では SSL でセキュリティサイトにアクセスしていることさえわかりづらい状況である。 　電子商取引を行う際にはスケーラビリティが要求される。すなわちモール側では不特定多数に対して商取引を行いたいのである。そのためにこのようにブラウザに認証局の証明書を組み込む方法が取られている。
電子商取引などのような広い範囲での利用ではなく、ある閉じた範囲内で有効であればよい場合もある。実際プライベート CA などと呼ばれる社内 CA の構築がこの一例である。 　社内で稟議書をまわすなどの社内業務でのセキュリティ（認証と暗号化）を確保する目的で利用するのであればこの方法で十分である。しかし閉じた世界（＝社内）でしか通用しない公開鍵証明書であるため、社外では何の効力も持たないこととなる。
図 9 認証局
これは証明書の検証者が証明書の発行主体つまり認証局を信用するかどうかに依存しているためである。現在も複数の認証局が乱立しており、公開鍵証明書の形式や検証方法は同じでも、主体も運営方針も異なっている。 　認証局は信用の基点となる役割を持つ。ユーザは多くの認証局の中から自分の信用のおけるものを選択し、信用せねばならない。どの認証局の傘下に入るかどうかを決めるのは個人に任せられている。しかし InternetExplorer や NetscapeCommunicator の製品に既に組み込まれているように、この作業を怠っているのである。 　先に述べた社内認証局の応用例として相互認証を紹介しておく。Ａ社、Ｂ社ではそれぞれＡ社CA，Ｂ社CA が運用されている。Ａ社の社員 a はＢ社の社員 b の証明書を検証したいがＢ社CA から発行された証明書であるため検証できない。 　そこで Ａ社 CA では Ａ社CA -> Ｂ社CA という証明書を発行し、Ａ社内に流布しておけば、Ｂ社内でしか通用しなかったＢ社証明書がＡ社内でも効力をもつことができる。 Ｂ社でも同様の操作をすることで相互にやりとりすることができ、企業間取引などの用途で有効である。
図 10 相互認証の例
しかし１社1社ごとにこのような作業を行うこと方式は煩雑かもしれない。つまり企業間でのやり取りの際には同業種で信用のポイントとなる認証局を立ち上げて利用するという少し大きなスケーラビリティを持ったインフラが有効である。 　このように認証局の傘の大きさ（有効範囲）によって用途を変えた運用が必要である。
暗号技術を用いることで、仕組みとしては安全にクレジット番号などの個人情報を安全に守ることができたとしても、ユーザが伝える相手すなわちモール側で適切な利用がされているかについては保証されない。 　途中の経路は安全に守ってもプライバシ情報の流出は防ぐことができず運用・体制の仕組みでカバーする必要がある。 このようなプライバシ保護問題を解決するためにプライバシーマーク制度が存在するが、世間への認知度は低い。これもユーザ側の意識が低いためと思われる。 　セキュリティを確保するためには、ユーザ側の煩雑さと安全性の確保は相反するところがある。しかし使いやすさ・わかりやすさを追求するのではなくユーザの意識を高めることが先決であり、このような啓蒙活動は重要である。