безопасный обмен данными с контрirbis_alпропущено...


А я вот тоже поддержу...
Все эти сертификаты и т.д не нужны как минимум на старте.
Делаете web приложение по принципу кабинетной системы.
протокол https
клиент зашёл в кабинет загрузил файл.(написал сообщение).
Вы его получили.(то,что получили из нужного кабинета и гарантирует то,что от нужного контрагента...(инженерная защищённость))
Можно чуть-чуть усилить. и сделать хеш-функцию(первый шаг цифровой подписи...без продолжения) на этот документ(сообщение) для гарантии того ,что документ(сообщение) не изменялся.
и проверять перед открытием на предмет совпадения хеш-ключей. хочу уточнить - документ не изменялся где ?

Означает В принципе не изменялся.с момента "посылки"
1.Клиент загрузил документ.
2.Система тут же посчитала его хеш-сигнатуру.
3.Записала этот хеш-ключ в базе или в конце документа.(это Вам решать ...главное чтобы эти реквизиты были ит-архитектурно связаны.)

Теперь Вы открываете документ...и перед открытием считается хеш...и если он не совпадает Вам выводится сообщение...."Что документ невалидный".

Для чего такая защита.
1.Если у Вас документы хранятся физически на файловой системе(ну например такая ит-архитектура )...и если кто-то получил к ней доступ мог изменить контекст....и тут хеш нам в помощь .
2.Если у Вас документы хранятся в Blop полях базы данных(более сильная ИТ архитектура)....уже документа сложнее поменять контекст....но всё равно можно...(Какой нибудь нерадивый админ СУБД минуя вашу ИС) и тут опять хэш в помощь.(как правило хеш алгоритм закрыт...и часто на клиненте...пожтому нерадивому админу будет ух как трудно ещё и хеш поле изменить на правильное в соответсвии с новым контекстом документа)

Спсбо, понятно. Таким образом мы пытаемся обезопасить данные от своих внутренних кротов.
Но нас в настоящее время больше интересует защита от внешних факторов - подмена письма или отправителя до появления у нас.

для этой задачи и достаточно https (как Вам выше многие и написали)