Вопрос или проблема
Я разрабатываю сервер ACME для выдачи удостоверений личности устройствам macOS/iOS для аттестации MDM, следуя RFC 8555. В соответствии с RFC клиент создает заказ, проходит авторизацию, проверяет задачу и завершает заказ, отправляя CSR в CA.
В моей конфигурации CA иногда требуется больше времени для выдачи сертификата (около 50 секунд). Согласно RFC 8555, если выдача сертификата не завершена после вызова /finalize, сервер должен ответить объектом “order” со статусом “processing”. Клиент должен отправить POST-as-GET запрос к ресурсу заказа (например, /order/<order_id>), чтобы проверить текущее состояние. Если CA все еще не выдал сертификат, сервер должен вернуть объект заказа с тем же статусом “processing” и включить заголовок “Retry-After”, указывающий, когда клиент должен повторить попытку. Ожидается, что клиент будет опрашивать ресурс заказа в этот указанный интервал с запросами POST-as-GET.
Однако, похоже, клиент Apple ACME игнорирует заголовок “Retry-After” и вместо этого сразу возвращает ошибку: “Профиль не удался – статус заказа в обработке, еще не действителен”, на первом ответе опроса с “processing”. Клиент Apple ACME отклоняется от документации RFC в случае асинхронного завершения заказа.
Кто-нибудь нашел надежное решение этой проблемы?
Чтобы обойти это, я удерживаю вызов /finalize до тех пор, пока CA не выдаст сертификат. Это работает, когда выдача быстрая (менее 20 секунд), но если это занимает больше времени, клиент выдает таймаут. Интересно, что таймаут клиента Apple ACME, похоже, короче, чем обычный параметр по умолчанию URLSession в 60 секунд.
Ответ или решение
Вопрос о работе клиента Apple ACME и его взаимодействии с сервером ACME в контексте обработки заказа является актуальной проблемой для разработчиков, занимающихся выдачей сертификатов. Давайте рассмотрим детали, связанные с этой проблемой, и предложим возможные пути её решения.
Проблема
При разработке сервера ACME для выдачи удостоверяющих сертификатов для устройств macOS/iOS возникает ситуация, когда клиент Apple ACME не может успешно опросить заказ с состоянием "processing". Согласно спецификации RFC 8555, если процесс получения сертификата занимает больше времени, чем ожидалось (в данном случае до 50 секунд), сервер должен возвращать объект "order" со статусом "processing". Ожидается, что клиент будет продолжать опрашивать ресурс заказа с помощью команды POST-as-GET, следуя при этом указаниям заголовка "Retry-After".
Однако, по имеющимся данным, клиент Apple игнорирует заголовок "Retry-After" и сразу же вызывает ошибку "Profile failed – Order status is processing, not yet valid", что указывает на несоответствие с документацией RFC.
Анализ проблематики
Клиент Apple ACME, похоже, имеет ограничения по времени ожидания, скорее всего, меньшее, чем стандартные 60 секунд, установленные для URLSession. Это может приводить к тому, что при задержках, превышающих этот временной лимит, запросы к ресурсу /order не получаются успешно обработаны. Обходной путь, который вы используете, задерживая выполнение вызова /finalize до момента получения сертификата, работает только в тех случаях, когда процесс получения сертификата занимает менее 20 секунд.
Возможные решения
-
Увеличение времени ожидания: Попробуйте настроить клиента с учётом более длительного времени ожидания для разрешения проблемы с тайм-аутами. Это может быть сделано через сетевые настройки, указания параметров тайм-аута или использования асинхронных функций, которые позволят избежать преждевременного прекращения ожидания.
-
Логика повторных попыток: Разработайте более сложную логику для клиента, которая будет учитывать срок действия заголовка "Retry-After". Примером может служить создание механизма опроса, который будет подключаться к ресурсу /order по истечении указанного времени, а не сразу.
-
Обновление клиента или сервера: Проверьте, доступна ли обновлённая версия клиента Apple ACME, где подобные баги исправлены. Также стоит рассмотреть возможность настройки или обновления вашего сервера для более качественного взаимодействия с клиентами.
-
Ведение журнала и отладка: Важно создать детализированный лог всех взаимодействий клиента и сервера, чтобы лучше понимать, где происходит сбой. Это может помочь не только в исправлении текущей проблемы, но и для предотвращения подобных в будущем.
Заключение
Недостаток понимая спецификаций RFC или неправильная реализация в клиенте Apple может негативно сказаться на процессе выдачи сертификатов. Важно продолжать исследовать проблему, используйте действие и подходы, изложенные выше, для нахождения решения. Это также может стать причиной улучшения взаимодействия с клиентами и повысить общее качество системы в целом при выдаче удостоверяющих сертификатов.