A（依頼元）とB（サービス提供者）の通信における中間者攻撃（中間者はCと呼びます）の対策の1つとして証明書の利用があると思います。

なぜ証明書が対策になるのか、伺えませんてましょうか？

Bがサーバ証明書を導入している場合、CはBの秘密鍵を持っておらず、適正なディジタル署名を作れないために、BなりすましてAと通信することはできなくなる（＝中間者攻撃はできない）という理解であっていますか？

－－－－－－－－

次に、一般的な構成としてありえると思いますが、Aが社内プロキシサーバ（＝P）を経由して、Bと通信をする際のことを考えます。
※AとP、PとBの間は暗号化通信し、Pで通信チェックするために一度復号する前提とします。

（焦点が定まらない質問になりますが、）この時、Pは中間者の立ち位置となりますが、AとBの間で通信を問題なく中継できるのはなぜでしょうか？

Bの秘密鍵を知らないという今では、前述の中間攻撃者CもこちらのPと同じ立ち合いだと思います。

AはBに向けてリクエストしているのに、中間者Pの証明書をもとに問題なく通信できるあたりがよくわからないところです。

証明書が対策になる理由については、その理解であっていると思います。
－－－－
AとB間での通信については、
PはAの代わりに、Bへアクセスし証明書を受け取ることになりますが、その際PはBの証明書を検証し、異常がなければ、Bの証明書を自ら新しく作成します、そしてその証明書をAに渡し、Aがその証明書の検証行うことになります。しかし、Pが新たに作った証明書は当然、正規の認証局が発行したものではないため、Aのブラウザ上で、エラーが出てしまいます。それを回避するために、Pのルート証明書をAで「信用できるルート証明書」として登録します。そうすることで、AとBの間で通信を問題なく中継できます。

中間者Cの証明書は、Aで登録されていないため、エラーが出ますが、Pの証明書はAで登録されているため、エラーが出ません。

サーバ証明書はサーバが誰のものか、公開鍵は本物か安全かを表すものです。
サーバ証明書は攻撃者によって建てられた（？）認証局であっても発行は可能なため、攻撃者はドメインや会社、公開鍵を偽造したサーバ証明書も作れてしまいます。
しかし、攻撃者の偽造した証明書は、クライアントからしてみれば全く信頼できない認証局が発行しているとても怪しいものです。ブラウザには「信頼されていない機関によって証明書チェーンが発行されました。」と表示されるため、Aは中間者攻撃のおそれありと判断し通信を中断できるわけです。
（フールプルーフの観点から言うと、相互に証明書で認証するべきです。「なんやこれ、ようわからんわ」とせっかくブラウザが表示したメッセージを無視されてしまうと意味がありませんから...特別にソフトを開発するのであれば信頼されていない認証局のサーバ証明書を使った通信はしない設定にしておくとよいでしょう...）


問題なく通信できているのは、元々中継しているからです。正規の手順で中継しているからです。AはPを信頼し代わりに通信するようにと設定しているからです。
最初からAはPをサービス提供者と思い込み、BはPにサービスを提供し、PはAにサービスを横流ししています。これがプロキシサーバの根本的な仕組みです。そのため暗号化もA～PとP～Bの間で行われます。元から暗号化がその範囲だけで行われています。P内部では一時的に必ず平文になります。
詳しくはH26ネットワークスペシャリスト午後Ⅱ問１図３を参照してください。暗号化の手順が書かれています。

> なぜ証明書が対策になるのか、伺えませんてましょうか？
質問者様がサーバ証明書と呼んでいるものは、正確にはサーバで作ったSSL証明書の事かと思われます（ちなみに、クライアント側で作ったSSL証明書がクライアント証明書と呼ばれたりします）
このSSL証明書には様々な情報が含まれています。その中で特に重要なものは以下の①②のセットと③④のセットです。
①Webサーバの名前（FQDN）
②Webサーバの公開鍵
③認証局の名前
④認証局のデジタル署名
⑤その他

このSSL証明書は改ざんが困難な性質を持ちます（詳細は後述）
ですので、AはこのSSL証明書を持っているBが本人であることを信頼して、SSL証明書の②に入っている「Webサーバの公開鍵」を使って通信を暗号化してBに送信します。Cはこの証明書を入手してBを装う事はできますが、②の「Webサーバの公開鍵」に対応する「Webサーバの秘密鍵」はBしか持っていないため、通信を復号することができず、中間者としてなりすます事ができません。

ではなぜ証明書の改ざんが困難なのかと言いますと、
④の電子署名がポイントです。これはSSL証明書自体のデータのハッシュ値を算出した後、③の認証局が持っている「認証局の秘密鍵」で暗号化したものです。
Aは③に記載されている認証局が発行している証明書を予めブラウザにインストールしているので（これがルート証明書、または中間証明書）、この証明書の②に入っている「認証局の公開鍵」を使ってハッシュ値を復号します。
その後、自分が受け取ったSSL証明書のハッシュ値を自分で計算し、二つのハッシュ値が一致していることを確認することで改ざんされていないことを確認します。

なお、ルート証明書も中間証明書もSSL証明書も基本的に全て同じものです。発行者と認証者が違うだけです。
・ルート証明書の場合は①～④全てルート認証局自身です。
・中間証明書の場合は、①②が中間認証局で③④はルート認証局になります。
・SSL証明書の場合は、①②が一般のサーバ（あるいはクライアント）で、③④は通常、中間認証局になります。

> Bがサーバ証明書を導入している場合、CはBの秘密鍵を持っておらず、適正なディジタル署名を作れないために、BなりすましてAと通信することはできなくなる（＝中間者攻撃はできない）という理解であっていますか？
・CがB（サーバ）の秘密鍵を持っていないというのは、その通りです。
・上記の解説の通り、ディジタル署名を作るのは認証局です。ディジタル署名を作る上で必要なのは認証局の秘密鍵なので、仮にCがBの秘密鍵を入手できたとしてもディジタル署名は作れません。もちろん、デタラメなものであれば作れますが、Aのブラウザにインストールされているルート証明書（または中間証明書）にはそのデタラメなディジタル署名に対応する公開鍵が無いので、証明書の検証に失敗します。

> Pは中間者の立ち位置となりますが、AとBの間で通信を問題なく中継できるのはなぜでしょうか？
AがPに中継をする気があるからです。具体的には
①AのPC内のブラウザや専用ソフトに内蔵されているプロキシ通信の設定をしている
②プロキシ通信の宛先にPを指定している

最初からPと通信する気があるので、実際の通信先はBではなくPです。サーバ証明書もBのものではなくPのものが取得されます。宛先URLはBを指定したのに受け取った証明書に書かれている内容はPのものですが、内部のプロキシ通信機能がその不整合を許容しています。プロキシ通信機能としては、通信先がプロキシサーバ（P）であることが証明書で保証されていれば問題なく通信を行います。

ご回答下さった皆様ありがとうございます。おかげさまで理解が深まりました。

グルタミンさんの最後（以下）の記載について追加質問させて頂けませんか？

－－－再掲－－－
> Pは中間者の立ち位置となりますが、AとBの間で通信を問題なく中継できるのはなぜでしょうか？
AがPに中継をする気があるからです。具体的には
①AのPC内のブラウザや専用ソフトに内蔵されているプロキシ通信の設定をしている
②プロキシ通信の宛先にPを指定している

最初からPと通信する気があるので、実際の通信先はBではなくPです。サーバ証明書もBのものではなくPのものが取得されます。宛先URLはBを指定したのに受け取った証明書に書かれている内容はPのものですが、内部のプロキシ通信機能がその不整合を許容しています。プロキシ通信機能としては、通信先がプロキシサーバ（P）であることが証明書で保証されていれば問題なく通信を行います。
－－－再掲－－－

AはプロキシにPを設定しているとしても、ブラウザに指定するURLはアクセスしたい先（＝BのURL）になると思います。（ただ、プロキシ設定によりまずは、プロキシにリクエストして、プロキシがBに中継すると理解しています。）

ここで疑問があります。
Aのブラウザからすると、BのURLにリクエストしているのに、証明書の①はP（プロキシサーバ）のFQDNとなっていて、BのURLと異なるためAのブラウザ上は警告画面になるものと思いますが、この理解はズレていますか？

また、参考書やテキストなど見ると、この証明書の①をBのFQDNにすれば、Aのブラウザで警告画面は出ない、となっているように見受けられます。

仮に、①をBのFQDNにすればAの警告画面が解決する場合、AとX、AとY、AとZなど、その他サーバ（X、Y、Zなも）との通信ではどうなりますか。
Pには、各パターン毎の証明書（FQDNをX、Y、ZのURLにしたもの）を準備、登録しておく必要があるのでしょうか？

～再掲～
①Webサーバの名前（FQDN）
②Webサーバの公開鍵
③認証局の名前
④認証局のデジタル署名
⑤その他
～～～

プロキシサーバの仕組みについては「SEの道標」さんのサイトが本当にわかりやすいので、是非、一度確認してみてください（サイトルールで禁止されているので、URLではなくタイトルだけ載せます。そのまま検索してみてください）
・【図解】httpプロキシサーバの仕組み(http GET/https CONNECTメソッド)や必要性・役割・メリットデメリット・DNSの名前解決の順序
・【図解】透過型プロキシの仕組み ～https(SSL/TLS)への対応～

前者の「プロキシサーバによるhttps通信の傍受」の②が凡そ質問への回答になるかと思います（いきなり読むとわからないかもしれないので、最初から読んでみてください）

その上で謝罪させていただきますと、大事な事を書いていませんでした。申し訳ありません（文章が長くなりすぎて後半はかなり内容を端折ってしまいました）
> 証明書に書かれている内容はPのもの
と書いてしまいましたが、正確には①のFQDNだけはサイトBのものです。これはアクセス先が変わるたびに動的にその部分をPが書き換えてAに渡します。しかし②の公開鍵や③④の認証局はP由来のものです。
そして、これは一般的にプライベートなものなので、Aのルート証明書には存在しません。
そのままだとAのブラウザで警告画面が出てしまいますので、事前準備としてPを信頼するように作成したルート証明書（いわゆるオレオレ証明書）を自分のところで発行してAにインストールしておく必要があります。

これですべての回答になっているか少し怪しいですが、正直、上記のサイトを見れば大体の疑問は解決するかと思われます。

それと
> 内部のプロキシ通信機能がその不整合を許容しています。
これは私の勘違いですね。プロキシ通信機能は証明書の仕組みに関与してこない（はず）です
私も理解があいまいなまま回答してしまいました。申し訳ありません。

グルタミンさん
ありがとうございます。ご記載頂いた内容は理解できます。

特に、「正確には①のFQDNだけはサイトBのものです。これはアクセス先が変わるたびに動的にその部分をPが書き換えてAに渡します。」のあたりで私の疑問が大きく解消されました。

なお、頂きましたサイトも確認したいと思います。

色々とありがとうございました。