В днс нельзя один токен добавить на всю жизнь домена?

Если ты с LE работал - ты даже если случайно токен потерял подсмотреть его е можешь

Я не хочу с тобой спорить. Прости. Ты никогда не слушаешь и получается бессмысленный флуд

@schors а почему не работает вариант с проксированием?

Бизнес-виртуалка? 100 рублей? С гарантированными ресурсами и специфицированным SSD? Да ну?

Нет. Я ругаю LE за то что это кусок говна. От самого протокола, до штатной библиотеки внутри

@schors а почему не работает вариант с проксированием?

чо?

чо?

Я видимо не понимаю о чем спор

Я видимо не понимаю о чем спор

Ну например ты терминируешь tls на кластере перед серверами

Уже начинается веселье с верификацией

Дьявол в деталях

Собственно мы в .m этот вопрос обсуждали долго

А если ляжет этот сервер?

Уже начинается веселье с верификацией

Так какое, если можно проксировать локейшн один и в общем быть достаточно довольным с виду

Ну типа HA, все дела.. не?

Так какое, если можно проксировать локейшн один и в общем быть достаточно довольным с виду

DNS-верификация рулит.

Так какое, если можно проксировать локейшн один и в общем быть достаточно довольным с виду

Ты не знаешь, на какую машину кластера приходит запрос каждый раз

А вот здесь уже пляски начнутся с синхронизацией же

Соотв. не знаю, гластер какой-нибудь сразу

Ты не знаешь, на какую машину кластера приходит запрос каждый раз

ты можешь отправить этот запрос на одну конкретную машину всегда. например, на машину, которая у тебя вкоммитит сертификат в puppet/salt/chef

но DNS-верификация решает эти проблемы совсем. вам даже сайт работающий не нужен.

Ты не знаешь, на какую машину кластера приходит запрос каждый раз

Не вижу проблем. Прокси пасс на один из пары серверов и все

Што. Ты не отправляешь запросы, это ле делает

Конкретных локейшенов

Што. Ты не отправляешь запросы, это ле делает

а ты их принимаешь.

Ебать у нас с вами мисматч масштабов, ребята

Ебать у нас с вами мисматч масштабов, ребята

уверен?..

Вы хотите в одной точке ловить локейшн и кидать его на конкретную мпшину? А не дохуя ли это точка отказа

Ебать у нас с вами мисматч масштабов, ребята

Ну мы покрупнее будем да

И что?

Вот чувак выше еще крупнее

Я даже рискну сказать что на порядок

Я говорю все это по опыту работы в мастерхосте если что

но DNS-верификация решает эти проблемы совсем. вам даже сайт работающий не нужен.

Только ты прикрути DNS-верификацию к станлдартному чему-нибудь

Только ты прикрути DNS-верификацию к станлдартному чему-нибудь

я прикручивал.

Не гигант, но и не маленький хостинг

route53 ок, руцентр ок, яндекс-пдд ок, кастомный паверднс с апи - ок. прикрутить можно к чему угодно, где можно автоматически добавлять записи

я прикручивал.

Не. Я не говорю что нельзя. Но там ни у кого из них нет точки куда штатно воткнуться

Не гигант, но и не маленький хостинг

Я понимаю, но все равно уверен что контора где работает Сергей минимум на порядок больше

Пока я слышу разговоры тут про ололо у меня два нжинкса и я где-то в одной точке терминирую http/s

Я понимаю, но все равно уверен что контора где работает Сергей минимум на порядок больше

Да? :)

Не. Я не говорю что нельзя. Но там ни у кого из них нет точки куда штатно воткнуться

да ладно? япдд - одна строчка на курле. https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks

Это ну блядь смешно

Пока я слышу разговоры тут про ололо у меня два нжинкса и я где-то в одной точке терминирую http/s

Одна точка это вполне может быть ecmp поверх сотни серверов

Например

Это ну блядь смешно

не смешно. у вас проблема будет скорее не в отказоустойчивости, а в лимите количества сертификатов выпускаемых LE.

не смешно. у вас проблема будет скорее не в отказоустойчивости, а в лимите количества сертификатов выпускаемых LE.

Да-да, но это решаемо письмом к нии.

да ладно? япдд - одна строчка на курле. https://github.com/lukas2511/dehydrated/wiki/Examples-for-DNS-01-hooks

Бля. Ну так это чьё-то наколенное решение а не популярные сервера типа родного

Да? :)

Да

Да

Да?

Бля. Ну так это чьё-то наколенное решение а не популярные сервера типа родного

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

раз в X времени пускаем обработку всех известных сертификатов, узнаем записи, добавлям в днс, пинаем LE, чтобы они порезолвили, получаем новые сертификаты, деплоим.

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

Какой блять клиент? У меня perkele тоже умеет. Кто о нём знает? Кто об этом вжопузадирищенском клиенте знает?

Какой блять клиент? У меня perkele тоже умеет. Кто о нём знает? Кто об этом вжопузадирищенском клиенте знает?

а какая разница, какой клиент? или вам нужно (с), (ТМ) и (R)? certbot мб кстати тоже научился в DNS-верификацию, но тут сказать не могу.

нишо не понял. протокол есть, клиент есть, клиент умеет в хуки.

Ну т.е. челвоек молодец - сделал клиент с хуками. Но это немного не то, что предлагали выше

а какая разница, какой клиент? или вам нужно (с), (ТМ) и (R)? certbot мб кстати тоже научился в DNS-верификацию, но тут сказать не могу.

Я даже знать об этом не хочу уже :)))

Короче, это всё не отменяет, что проект гавно. Два годя блять подгонять хуки - это пиздец

Ну т.е. челвоек молодец - сделал клиент с хуками. Но это немного не то, что предлагали выше

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

Короче, это всё не отменяет, что проект гавно. Два годя блять подгонять хуки - это пиздец

ну хз. раньше я выпускал сертификаты через вебморды и деплоил их вручную. щас мне раз в два месяца приходят письма "обновлено". прогресс очевиден.

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

В случаи шаред хостинга может не быть контроля над днс клиента

да у меня поинт простой. вместо пляски с HTTP-верификацией (которую кстати вполне можно победить на большом масштабе) можно использовать DNS-верификацию, которая медленнее, но не требует активности на http вообще

Ну это понятно. И правильно. Я тоже так думал. Но есть проблема - я или не NS для домена, или домен на момих NS, но у меня нет API :)))

В случаи шаред хостинга может не быть контроля над днс клиента

В случае любого хостинга

В случаи шаред хостинга может не быть контроля над днс клиента

в случае шареда непонятны проблемы с http-верификацией вообще.

Ну это понятно. И правильно. Я тоже так думал. Но есть проблема - я или не NS для домена, или домен на момих NS, но у меня нет API :)))

всем бывает тяжело. :)

в случае шареда непонятны проблемы с http-верификацией вообще.

Ну не осилили люди, бывает

в случае шареда непонятны проблемы с http-верификацией вообще.

Ну там же написал человек всё правильно - много точек отказа. Я например клиента дербанил по кускам. Чтобы шаги контролировать. Не, я сделал. Но ни один стандартный клиент не справился с элементарной задачей

Ну там же написал человек всё правильно - много точек отказа. Я например клиента дербанил по кускам. Чтобы шаги контролировать. Не, я сделал. Но ни один стандартный клиент не справился с элементарной задачей

Один из контролей - это кстати деплоймент токена на бэкенд

Ну там же написал человек всё правильно - много точек отказа. Я например клиента дербанил по кускам. Чтобы шаги контролировать. Не, я сделал. Но ни один стандартный клиент не справился с элементарной задачей

эти точки отказа по идее вполне решены, если шаред норм. отказоустойчивый фронтенд есть. hot-standby бэкенд, который отвечает на LE-запросы - есть. этот бэкенд имеет право прилечь на единицы секунд без всяких проблем. в конце концов мы сертификаты выпускаем, а не транзакции делаем. distributed-lock + active-passive пачка бэкендов, плюс система деплоя сертификатов (у вас же уже есть она, правда?). не вижу проблем, которые в шареде не должны были быть уже решены.

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

эти точки отказа по идее вполне решены, если шаред норм. отказоустойчивый фронтенд есть. hot-standby бэкенд, который отвечает на LE-запросы - есть. этот бэкенд имеет право прилечь на единицы секунд без всяких проблем. в конце концов мы сертификаты выпускаем, а не транзакции делаем. distributed-lock + active-passive пачка бэкендов, плюс система деплоя сертификатов (у вас же уже есть она, правда?). не вижу проблем, которые в шареде не должны были быть уже решены.

Ничего не понял. Ну? Как в эту схему вписывается звездолет по имени certbot?

Ничего не понял. Ну? Как в эту схему вписывается звездолет по имени certbot?

а кто сказал сертбот? я не говорил. если очень хочется сертбот, то вы пущаете сертбот на том самом бэкенде, который в текущий момент active. запросы от LE проксируете со всех фронтендов на этот бэкенд. сертбот и не подозревает обо всей этой ебанистике. естественно, он должен работать в режиме cert-only и просто складывать сертификат вместо попыток переписать конфиги веб-серверов. вы подхватываете сертификат и пихаете в систему деплоя сертификатов.

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

а кто сказал сертбот? я не говорил. если очень хочется сертбот, то вы пущаете сертбот на том самом бэкенде, который в текущий момент active. запросы от LE проксируете со всех фронтендов на этот бэкенд. сертбот и не подозревает обо всей этой ебанистике. естественно, он должен работать в режиме cert-only и просто складывать сертификат вместо попыток переписать конфиги веб-серверов. вы подхватываете сертификат и пихаете в систему деплоя сертификатов.

Чо? Какй в жопу active? Они все active

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

мб. но альтернатив нет и оно работает.

мб. но альтернатив нет и оно работает.

Хуево работает. Вон те же IDN - анонсировали в октябре, не работает по сей день

Чо? Какй в жопу active? Они все active

это у вас в голове они active, а для того чтобы ванильный сертбот работал на некластерной fs нужен active-passive.

Хуево работает. Вон те же IDN - анонсировали в октябре, не работает по сей день

альтернативы-то есть?

Чуваки. Я вот прочитал весь срач. Думал пойму в чем конкретно проблема. Но нет. Столько эмоций по типу "Ааааа ничего не работает". Фил, вот без "блять", "хуево" и т.д. ты можешь описать, что не так с LE конкретно в твоем случае? Потому что у он настроен на 146% автоматически обновлять сертификаты на хостинге картинок. А там у меня 3 TL-домена и у каждого из них есть и 2го, 3го уровня и 4го уровня поддомены. На всех серты LE.

альтернативы-то есть?

нет. это понятно

ну у ребят десятки тысяч (или сколько?) доменов, там не пять минут три раза в месяц, там нужно более автомагически.

Чуваки. Я вот прочитал весь срач. Думал пойму в чем конкретно проблема. Но нет. Столько эмоций по типу "Ааааа ничего не работает". Фил, вот без "блять", "хуево" и т.д. ты можешь описать, что не так с LE конкретно в твоем случае? Потому что у он настроен на 146% автоматически обновлять сертификаты на хостинге картинок. А там у меня 3 TL-домена и у каждого из них есть и 2го, 3го уровня и 4го уровня поддомены. На всех серты LE.

1. Неоправданно громоздкий протокол. В нем много лишнего и нет простых вещей. Например нельзя проверить, когда протухает валидация домена. Оазбираться в нем не один час. 2. Стандартная библиотека написана с ООП головного мозга бездумно. С дичайшими костылями, рассказывающими нам об истории развития протокола. Использовать стандартную библиотеку в своих утилитах сложно. Мне например не удалось адекватно разорвать запрос на токен и запрос на проверку токена. 3. Стандартные решения автоматизации реализованы как чорный ящик. Хорошо если нашлепнуты хуки. 4. Боевой сервер кривоватый. Например неработа IDN из-за рукожопия архитектуры сервера