В вашем вопросе и в комментариях к нему вы, кажется, особенно заинтересованы в

• можно ли использовать API подписи, который возвращает сертификаты только вместе с подписью, и
• когда следует отложить подписание.

Можно ли использовать API подписи, предоставляющий сертификат пользователя только после подписи?

Чтобы ответить на этот вопрос, сначала необходимо уточнить, какие подписи создает рассматриваемый API подписи, простые значения подписи (например, подписи RSA PKCS # 1) или полноценные контейнеры подписи CMS.

Если он создает полноценные контейнеры сигнатур CMS, вы можете создавать сигнатуры по произвольным профилям сигнатур, если контейнеры сигнатур соответствуют их требованиям (что они часто и делают). Единственное ограничение, которое у вас есть, заключается в том, что вы не можете иметь информацию из сертификата подписавшего в визуализации подписи, потому что эта визуализация определена в подписанных данных PDF.

Если он создает только простые значения подписи, лучшее, что вы можете сделать, - это создать и встроить простые контейнеры CMS, которые не содержат указателей на сертификат подписавшего в подписанных атрибутах (если у них есть какие-либо подписанные атрибуты для начала). Многие политики подписи, представляющие интерес, действительно требуют таких указателей, но, по крайней мере, Adobe Reader принимает подписи без них.

Если вы находитесь в этой ситуации и хотите попробовать создать подписи с такими простыми контейнерами подписи, вы можете использовать код из этого ответа, раздел Как создать подпись PDF без предварительного знания подписывающего сертификата.

Когда использовать отложенное подписание

Разница между отложенной подписью и другими вызовами подписи iText заключается в том, не то, что для отложенной подписи требуется меньше информации (по сравнению с подписью ExternalContainer).

В отличие от других методов подписи iText, signDeferred повторно использует самое внешнее существующее заполненное поле подписи PDF-файла для подписи и просто заменяет контейнер подписи в нем.

Название метода происходит от наиболее распространенного варианта его использования:

• На первом этапе поле подписи (возможно, сначала создается, а затем) заполняется с использованием signExternalContainer с реализацией IExternalSignatureContainer, которая вычисляет хэш документа для подписи, но еще не возвращает окончательный контейнер CMS, а просто некоторый (обычно) пустой массив. Сгенерированный PDF-файл с заполненным полем подписи (хотя и без окончательного контейнера подписи) затем временно сохраняется (в файловой системе или базе данных).
• На втором этапе контейнер подписи для определенного хэша документа запрашивается и (возможно, асинхронно) ожидается.
• На последнем этапе signDeferred используется для вставки полученного контейнера подписи в PDF-файл, подготовленный на первом этапе.

Этот отложенный процесс подписания обычно предпочтительнее в настройках, в которых второй шаг, создание и извлечение контейнера подписи, может занять больше времени, чем нужно, чтобы заблокировать ресурсы, необходимые для подписываемого документа. Это включает, в частности, подписи, сгенерированные удаленными серверами или клиентами, особенно если этот процесс подписания ожидает разрешения или активации третьей стороны.