Има една пасмина хора въ този свѣтъ, има една, тъй да се каже, излишна категория люде, които сѫ скѫсали всички отношения съ законитѣ, битието, съ повеленията на науката, съ традициитѣ на човѣшкия родъ!
И тази пасмина, тази зловредна категория люде, казвамъ ви най-откровено, сѫ ергенитѣ. Какво представляватъ тия отхвърлени отъ човѣшкото общежитие индивиди? Нищо. Нулъ! Представляватъ само една ненаситна консумативна глутница, която пълни общественитѣ заведения съ единствената цель за задоволяване егоистичнитѣ си нагони (питие, ежбина, плезиръ д’амуръ на дребно).
Никакво чувство къмъ пестиливость – основата на стопанския животъ; никаква загриженосъ къмъ продължение на рода человѣчески, никакво съзнание за половия подборъ (наученъ терминъ) – проблемъ единъ видъ тъй ясно обясненъ отъ госпосдинъ Дарвинъ, комуто мнозина тия дни устроиха хвалебни тържества въ знакъ на благодарность за дето е открилъ пра-пра-прадѣдитѣ имъ.
Подборъ ли? Никакъвъ подборъ по гореспоменатия деликатенъ въпросъ, казвамъ ви, не притежаватъ обвиняемитѣ ергенски ствари, а просто тъй. . . безъ подборъ си изживяватъ и днитѣ, и нощитѣ, и цѣлия животъ.
Търпѣхме до сега. Но търпението ни изчезна! И сме решени да обявимъ редъ конферанси и лекции и съ несъкрушими данни и аргументи да приковемъ всичкитѣ ергени на позорния стълбъ за назидание и поука!
Заучили зловреднитѣ му типове по нѣколко стихотворения отъ г-нъ Пушкинъ и другитѣ поети и търсятъ изгоденъ моментъ (флиртъ), за да ги пришепнатъ съ задушевность на ухото на съответния нѣженъ полъ:
„Поцѣлуй меня, потомъ я тебя“. – Точно такива работи, казвамъ ви, пришепватъ на въпросния полъ обвиняемитѣ. И понеже нѣжниятъ полъ отъ подобни слова се разнѣжва още повече, цельта съ поцѣлуя се постига и стихотворението се пренася, за да се пошепне на друго ухо, отъ тамъ на трето, на четвърто и т.н.
Научили по едно танго идивидитѣ му и на това основание прегърне жената на току-що запознатия уважаемъ съпругъ и почне:
„Испанско танго и красиви жени и желание страстно ме облива тозъ часъ“.
Стѫпва, казвамъ ви, ергенската мафия въ тактъ съ музиката, примижава съ очи и се държи тъй невинно, като че ли е първи братовчедъ на Исусъ Навинъ.
А то въ същностъ… флагрантонсть най-долна проба.
Дойде праздникъ, порядъчното общество изведе фамилията си на разходка, още по-порядъчното изведе заедно съ фамилията си и надлежната високоуважаема тъща, а най-порядъжното заедно съ тѫщата изведе и съответнитѣ балдъзи (радость въ кѫщи), за да имъ се полюбува околната срѣда и да ги хареса съ цель за задомяване. Т а к а постъпва въ праздниченъ случай, повтаряме, порядъчното общество! А какъ, какво прави въ сѫщия моментъ ергенската срѣда? Лежи. Лежи и спи и не може да дойде на себе си отъ б е з п ѫ т н а т а нощь, к о я т о е п р е к а р а л а по разни питейни и прочие заведения. И не само че никого на разходка не извежда, но и сама я мързи тая срѣда, да раздвижи тѣлесата си съ цель за освежаване на организмитѣ и за изтрезвление на съзнанието. А за симулация предъ родителката си казва, че я боли глава отъ настинка и иска аспиринъ или пирамидонъ, или въ краенъ случай армеена чорба.
Дойде Великдень. Уважаемото г р а ж д а н с т в о вземе авансъ, купи за децата и жената каквото трѣбва или поне частица отъ това, каквото трѣбва, и се готви да посрещне свѣтлия праздникъ въ тихъ семеенъ кѫтъ, както се казва. А безприютната ергенска стварь по това време ще я намѣрите да виси самотна по рестарантитѣ като остаряла кобила край стърнище, никому ненуждна, никому неполезна! Седи мрачна и намусена, кара се съ келнеритѣ, че въ яденето има тараканъ или невинна м у х а и п у х т и к а т о биволъ по нанагорнище. А, ако, недай Боже, гледайки положението ѝ, съжалите тая ергенска стварь и я посъветвате да вземе да се ожени, та да премахне това кучешко тегло, ще отвори едни уста и ще изсипе огньове и мълнии срещу невиннитѣ, милитѣ и високоуважаеми тъщи:
– Звѣрове, душегубници, змии!
Така ще закрещи, казваме ви! И, разбира се, нѣма да има никакво право. Тѫщитѣ сѫ най-милитѣ, най-д о б р и т ѣ, най-человѣколюбивитѣ и прочие най, най, най – с ѫ щ е с т в а. К а т о речатъ „зеть ми“, каточе нектаръ се прецежда отъ зѫбитѣ имъ (изкуствени и не). Не ги е грѣхъ, казвамъ ви, тия ергенски ствари тъй лошо да говорятъ по адресъ на уважаемитѣ (високо) майки на милитѣ съпруги!
И прочие и прочие. Нѣма защо да привеждаме много примѣри, за да докажемъ, че ергенството е социално зло! Достатъчно е да припомнимъ само поговорката, която дава за тая излишна категория организми следната дефиниция: „Ергенъ човѣкъ, е съдранъ човалъ“.
Презрете ги, драги! Не се сбирайте съ тѣхъ и ги сочете съ пръстъ. И, ако вземете отъ тѣхъ пари въ заемъ, не имъ ги връщайте. Наложете имъ 70 на сто ергенски одръжки. Обложете ги съ тежки данъци и на устата имъ турете по единъ апаратъ – нѣщо като таксиметъръ, който да брои всѣко тѣхно съприкосновение съ у с т а т а на о б р а т н и я п о л ъ. И всѣко цѣлувателно деяние да се таксува съ съответната такса за въ полза на държавата. А ако никакви наказания не помогнатъ… чисто и просто оженете ги по заповѣдь. Само така обществената съвестъ ще получи възмездие на всички злочинства, които ергенитѣ – най-тежкото социално зло – му сѫ нанесли.
Често възникват въпроси, относно „поощряването“ на клиенти на безжични мрежи да използват по-подходяща точка за достъп. В тази статия документирам настоящите си виждания относно този проблем.
Въведение
Речник
STA – станция – клиент на дадена безжична мрежа.
BSS – basic service set, базово множество услуги – точка за достъп и всичките ѝ клиенти.
ESS – extended service set, разширено множество услуги – няколко BSS-а, свързани чрез система за дистрибуция.
DS – distribution system, система за дистрибуция – системата, чрез която множество BSS-и са свързани в един ESS. Ще подразбирам Ethernet сегмент.
Roaming – роуминг – преминаване от един към друг BSS в един и същи ESS.
Client steering – насочване на клиенти – активно действие от страна на точка за достъп, което кара клиент да се асоциира с определен BSS.
Band steering – насочване към честотна лента – като client steering, само че насочва клиента към BSS в по-предпочитана честотна лента.
Стандартизация
IEEE 802.11 стандартите изрично отбягват специфицирането на „настойчиви“ действия и логика от страна на точките за достъп, що се отнася за насочване на клиентите. С други думи, когато се говори за избор на BSS, с който да се асоциират, топката е ИЗЦЯЛО в ръцете на STA имплементациите. Отказ от асоциация, на базата на друго, освен липса на правомощия за асоциация, е в разрез със стандартите.
Поправки на IEEE 802.11 с отношение към роуминг и насочване на клиенти – IEEE 802.11f (нестандартизиран), IEEE 802.11r, IEEE 802.11k, IEEE 802.11v, IEEE 802.11ad.
Съществуващи имплементации на насочване на клиенти
Решения със затворен код
Почти всеки сериозен производител на Wi-Fi хардуер, има собствена нестандартизирана имплементация на client и band steering. Няма да навлизам в детайли за Cisco, Aruba, UBNT, защото имплементациите им са затворени и нямам наблюдения над тях, освен за съществуването им.
hostapd
В де-факто стандартната имплементация на точка за достъп за Linux съществуват имплементирани както стандартизирани, така и нестандартизирани методи за насочване на клиенти.
Нестандартизирани подходи за насочване към честотна лента в официалните версии на hostapd
hostapd поддържа два подхода за насочване към честотна лента – отказ от отговор на probe request, ако даден клиент е бил забелязан на интерфейс в 5 ГХц честотна лента, или отказ от асоциация при същото условие[1]. И двата са доста „непохватни“, защото не взимат предвид това дали клиентът не би имал проблем при свързването към BSS-а на другия банд.
Важно е да се отбележи, че гореспоменатите два подхода могат да бъдат използвани само в случай, че една и съща инстанция на hostapd управлява всички физически интерфейси. Това е в разрез с текущата имплементация в OpenWrt и LEDE, при която за всеки физически интерфейс се стартира отделна инстанция на hostapd. Въпросът за изоставяне на сегашната имплементация беше отхвърлен от разработчиците на LEDE, защото би изискал сериозни промени в LEDE и ще направи системата по-малко отказоустойчива – при проблем с hostapd на един интерфейс, ще спре и другия.
Също така, не е имплементиран начин споменатите в [1] таблици от съседи да бъдат споделяни между отдалечени инстанции на hostapd. Това прави описаните в [1] подходи неприложими или поне непредвидими, при използване на повече от едно устройство в един ESS.
Нестандартизиран подход за насочване към честотна лента във форка на hostapd на Google
В доста информативна лекция по темата[2], служител на Google представи собствената им интелигентна имплементация[3] на band steering.
Плюсовете на тази имплементация пред вече съществуващата в hostapd са:
Взима предвид потенциални проблеми при свързване към BSS-а на 5 ГХц.
Предвидена е да бъде използвана в сценарий, при който отделна инстанция на hostapd управлява всяки отделен физически интерфейс.
За съжаление обаче е неизползваема в контекста на ESS с повече от една точка за достъп на отделни устройства.
Бих бил много щастлив, ако някой се заеме и имплементира дистрибутиран списък с клиенти, с който да работи тази имплементация. Нужна ни е за Open Fest.
Насочване към честотна лента чрез специфицираните в IEEE 802.11ad инструменти
IEEE 802.11ad въвежда промени, чиято цел е да улеснят избора на правилния банд от клиенти. В повече детайли – въвежда се MB (като multi-band) информационен елемент в beacon фреймовете на BSS-ите и метод за бързо прехвърляне на клиентска сесия между отделни BSS-и. В hostapd и wpa_supplicant от относително скоро съществува имплементация и за двете, но е скрита за конфигурационен флаг[4].
Положителното на тази имплементация е, че е стандартизирана от IEEE, но носи и редица отрицателни характеристики:
Изисква поддръжка от клиентска страна.
Нужно е една инстанция на hostapd да управлява всички физически интерфейси (като при 2.2.1).
Нова е, неистествана е и преди всичко – не е активирана по подразбиране.
Насочване на клиентите чрез средствата на IEEE 802.11r, k и v.
От Cisco са описали по същество що е то Assisted Roaming чрез използването на горните стандарти[5]. Препоръчвам да прочетете статията за детайли. Обобщено обаче, идеята зад методите за улесняване на решенията за роуминг зад тези поправки, е следната:
Точките за достъп събират информация за използването на радио ефира както от станциите в обхвата им, така и на база на собствените си наблюдения. Тези данни се предоставят на всяка станция и се очаква имплементацията на всяка станция да вземе решение към кой BSS да се асоциира.
В hostapd и wpa_supplicant изглежда съществуват поне частични имплементации[6]. Предстои да ги проуча и тествам преди Open Fest.
Огромният недостатък е, че е нужно клиентите да имплементират дадената логика за избор на BSS.
Насочване на клиентите чрез ограничаване на мощността на излъчване на мрежовите карти на точките за достъп и избор на кодировки за висока производителност
Най-изпитаният и най-широко съвместим метод за „поощряване“ на клиентите да преминат към друг BSS остава внимателното избиране на подходяща мощност на излъчване от страна на точките за достъп. Това, комбинирано с ограничаването на basic rate-овете до 54Mbps исторически винаги е работило доста добре на Open Fest[9].
Особености при роуминг
При преминаване от един BSS към друг в контекста на един и същи Ethernet сегмент съществуват няколко особености, за които трябва да бъдат взети мерки.
Обновяване на кеша на L2 устройствата в Ethernet сегмента
Две точки за достъп могат да бъдат свързани чрез два различни порта на суич или дори чрез отделни суичове. Докато мигриралият от един към друг BSS клиент не изпрати фрейм, която да обнови кешовете на L2 устройствата в мрежата, трафикът, адресиран до него, ще продължи да бъде изпращан до предходната му точка за достъп.
В hostapd съществува частична имплементация на невлязлата в сила поправка IEEE 802.11f, която се грижи при свързване на нова станция да изпрати от нейно име LLC фрейм до целия Ethernet сегмент[7].
С наскоро приет пач, IAPP имплементацията в hostapd вече работи и при двубандови точки за достъп[10][11].
Ускоряване на свързването с новия BSS
IEEE 802.11r дефинира два подхода за ускоряване на свързването с BSS-а, към който даден клиент преминава. Това е нужно, защото началното ръкостискане при WPA и ОСОБЕНО при WPA Enterprise е доста времеемко.
Двата подхода са preauthentication по въздуха и preauthentication по системата за дистрибуция. hostapd поддържа поне ft-over-ds[8] за WPA И за WPA Enterprise.
Бъдещи имплементации
На базата на проучването ми на имплементацията на 802.11r, k и v, може да се oкаже, че от нова имплементация на client steering няма нужда, но това ще стане ясно по всяка вероятност чак след OF, ако изобщо.
Междувременно, ако е нужна нестандартизирана имплементация, бих препоръчал да се надгради форка на Google с дистрибутирано изграждане на съответните списъци от станции и да се добави допълнителна логика, която да взима предвид информация за качеството на връзката със станциите.
Следва резюме на редица научни статии, които разглеждат проблеми с текущите стандарти и имплементации на лични документи с биометрични данни и изводи от наблюдения върху текущия законодателен процес за въвеждане на лични карти с биометрични данни.
Компроментиране на частния ключ, съответстващ на публичния ключ, използван за шифриране на биометричните данни[@Heimo-abuse]
Липса на механизъм за управление на достъпа до личните данни от гражданите[@Hoepman-epassport] (например ограничаване на достъпа само до снимка, само до пръстови отпечатъци или само до изображение на ирис).
Естеството на биометричните данни не позволява отказ от тях в случай на компроментирането им[@Kosta-epassport]
Неясноти от етична гледна точка
Конфиденциалност: Може ли гражданин да откаже или ограничи употребата на биометричните си данни от институции, на които няма доверие?[@Sprokkereef-ethicalpractice]
Ясна цел: Съществува ли защита срещу неоторизирана употреба на биометричните данни, отвъд начално дефинираната им цел? Могат ли допълнитени функции да бъдат добавяни с течение на времето? Може ли липсата на ограничения „ясна цел“ да доведе до злоупотреба с биометрични данни и от страна на публичния и от страна на частния сектор?[@Sprokkereef-ethicalpractice]
Например, опитът при въвеждането на биометрични паспорти във Финландия през 2006-а говори, че при втората част на въпросната реформа (през 2009-а година), е взето решение да се изгради национален регистър на пръстови отпечатъци. Дори в рамките на съответния законодателен процес, целите на регистъра са разширени неколкократно, включително чрез предоставянето на достъп до него на полицията.[@Heimo-abuse]
Пропорционалност: Биометричните данни адекватни, релевантни и пропорционални ли са, спрямо целта, за която са събрани?[@Sprokkereef-ethicalpractice]
Липса на проучване за оценка на ефекта от въвеждането на биометрични данни в личните карти
Не е проведено проучване, което да измери очакваните положителни последствия от въвеждането на биометрични данни в личните карти.
Липсата на подобно проучване в контекста на България прави въвеждането на биометрични данни необосновано, що се отнася до полезност и лишава от мотивация всички компромисни технологични и финансови решения, които трябва да бъдат направени в процесите на дизайн и имплементация.
Недостатъци от финансова гледна точка
Добавянето във всички лични карти на електроника, която да реализира функционалност, от която ще се възползват ограничен брой граждани, ще оскъпи необосновано изработката на личните документи.
Последствия
Последствията от изброените проблеми са непредсказуеми, но може да се спекулира какви могат да бъдат. Ето няколко примера за сценарии, които биха могли да се разиграят след въвеждане на биометрични данни в личните документи:
Предвид наличието на техническа възможност за въвеждане на биометрични данни в личните документи, промяна на законодателството така, че присъствието на биометрични данни да стане задължително за всички български граждани.
Автоматично взривяване на бомба в близост до определен гражданин, гражданин на определена държава или група граждани на определена държава.
Масово отдалечено събиране на биометрични данни от органите на реда в случай на протест.
Злоупотреба с биометрични данни от лица с достъп до изграден регистър на биометричните данни на всички български граждани.
Изтичане на регистър с биометричните данни на всички български граждани.
Заключение
Въвеждането на техническа възможност за присъствие на биометрични данни в личните карти ще доведе до отрицателни последствия за гражданите, а потенциалните положителни последствия не са оценени. По-голямата част от научните изследвания на личните документи с биометрични данни достигат до заключението, че трябва да не бъде използвана технология за безконтактен достъп до данните в личните документи. Заключението ми е, че въвеждането на биометрични данни на този етап е в най-добрия случай необосновано, а в най-лошия – ще изложи на риск от кражба на идентичност гражданите, чиито биометрични данни присъстват в личната им карта.
Има една основна разлика – HTTP/2 дефинира черен списък от комплекти от шифри, които не могат да бъдат използвани. Този списък е доста обширен, за да го обобщя – може да се използват само AEAD шифри с ефимерна обмяна на ключове. В противен случай Firefox и Chromium отказват да отворят сайта. Chromium с грешка INADEQUATE_SECURITY, а Firefox – без грешка – дори в конзолата.
Може би би било добра идея nginx да изписва грешка или предупреждение, че се използват непозволени шифри, но това е друг въпрос.
Низът от шифри, който използвам за https://petko.me е следният:
Преди повече от месец, в Twitter акаунта на Let’s Encrypt беше обявено записване за бета програма, което ставаше, посредством попълване на Google формуляр. Въпреки че намерих за ироничен факта, че разчитат на Google, реших да изпратя заявка.
Формулярът беше изключително прост – поле, в което да изредиш за кои домейни искаш сертификати и поле за E-Mail адрес.
Малко повече от седмица след това получих E-Mail, че домейните, за които съм поискал да бъдат подписани сертификати, са одобрени. Ето съдържанието на E-Mail-а:
Thank you for your interest in our beta program! We’re excited to let you know that your domains (below) have been whitelisted, and you can now utilize an ACME client to obtain a certificate for them.
Quick Start
To use Let’s Encrypt’s official client to obtain your real certificates, you will need to provide the production API URL on the command line:
If you are using a different ACME client, be sure to configure it to use the production URL in order to get valid certificates. Many clients will default to the staging URL.
Certificates from Let’s Encrypt are valid for 90 days. We recommend renewing them every 60 days to provide a nice margin of error. As a beta participant, you should be prepared to manually renew your certificates at that time. As we get closer to General Availability, we hope to have automatic renewal tested and working on more platforms, but for now, please play it safe and keep track.
Rate Limiting
During this beta test we have very tight rate-limiting in place. We plan to loosen these limits as the beta proceeds.
There are two rate limits in play: Registrations/IP address, and Certificates/Domain.
Registrations/IP address limits the number of registrations you can make in a given day; currently 10. This means you should avoid deleting the /etc/letsencrypt/accounts folder, or you may not be able to re-register.
Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Top Level Domain + Domain. This means if you issue certificates for the following domains, at the end you would have what we consider 4 certificates for the domain example.com.
The limit on Certificates/Domain has a window of 60 days, to give 30 days for renewals. We know it’s restrictive at present; thank you for your patience in helping us ensure Let’s Encrypt is ready for the whole world.
Certificate Transparency
Part of our transparency mission includes publicly disclosing the certificates we issue via Certificate Transparency. Your email address is not publicly disclosed.
След като набързо хвърлих едно око на изходния код на https://github.com/letsencrypt/letsencrypt, го клонирах на FreeBSD машината си и го изпробвах. Не ми допада, че letsencrypt-auto трябва да се изпълни с root привилегии, но изглежда работи доста чисто. Промените върху файловата система, които забелязах, са създаване на директории /etc/letsencrypt, в която се помещават ключовете и сертификатите и ~/.local/share/letsencrypt, в която е „виртуалната python среда“ на инструмента.
По подразбиране letsencrypt-auto прави няколко неща:
Създава средата, в която да се изпълни да се изпълни letsencrypt клиентът
Генерира чифт потребителски ключове, с които да се достъпва системата на Let’s Encrypt
Пита за кои домейни искаш сертификат (с curses-базиран UI)
Генерира 2048-битов ключ и CSR
Валидира домейните
Изпраща CSR-а за подпис
Записва получения сертификат в /etc/letsencrypt, заедно с пълната му верига сертификати
Както споменах, не ми хареса нуждата да изпълня скрипта с административни права. Освен това, не ми хареса от колко неща зависи под FreeBSD:
Изпълнението на този скрипт ми инсталира perl-5.20 и ми преинсталира(!) perl-5.18, без очевидна нужда за това.
Валидацията на домейните ми също беше доста неприятна – като начало, скриптовете не откриват наличието на nginx и те изправят пред избор (в грозно форматиран текст, който прилича на stack trace на python) – да създадеш файл в /.well-known/ на уеб сървъра, който отговаря за дадения домейн, или да спреш уеб сървъра и да изпълниш Bash-python black voodoo magic заклинание, което пуска уеб сървър, който сервира нужните данни. Ето как изглежда съобщението, което се показва след приятния curses-базиран диалог за избор на домейни:
Bash-Python Black Voodoo Magic:
Make sure your web server displays the following content at
http://petko.me/.well-known/acme-challenge/al8Z37ePxkms5jo0WtqguLq2aT7sQEd_S1IubcFzpwU before continuing:
{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "vhDQ-ssP5mgMd27zpovkmSD7oV3sjhTKdO2AU5N9GMkUMNsQ612dIa1sxXGErrW9WGlOa8EkPeK2T4JA5IBUNnuxJBJfT-EmT3suH2uW8klbFlJqHDIAHbnVZjVcrqKFS4Iuub5oaG0wPT4hPe4IKR3vob7DL7Yv0sgHwFFD0N8VWDCb6kG5HUqyvvMr6x0sPOyPQEzzJO-YWUwZM-FQ-sXLfxkBsI9hz9EqfaxvGV3wUVY_OOKMbKcyCM0e_sa7Vrd0jg_FEgHLW2dFVe1wdLLW4YEiimNHwINVloZxQ4QrSAaGI-aXJx1FojPGpkLwviSTmMGGC2MD7BSVqIzjiQ"}}, "payload": "eyJ0bHMiOiBmYWxzZSwgInRva2VuIjogImFsOFozN2VQeGttczVqbzBXdHFndUxxMmFUN3NRRWRfUzFJdWJjRnpwd1UiLCAidHlwZSI6ICJzaW1wbGVIdHRwIn0", "signature": "LCNiHNdZheeLCEcNG3JStH6J3pTZHqWL3Zne5AkzuFJ5NM8UQrhpAE-ie8E5VeXEGvXZFlJOpKU72rDmlaBQIyrWF1NLHh1A9vbTdPf_xa1lwVvASAFnvgcUU0c7o--5BegP4GEeWHkeOpqi5s45f-ktNUxtPuY9KrK_ByEQdcwfTcaUGwgOy86Oy-zVfyU45K6e-7fGahXLmrmcG9ADf4EQFVAx6Kax42kTkGl9oS-IiitQcCkc7pZA8nDWG_D6f5u01bBvBOn4PewBauajBr5fOX1StIi4ealnDKq0mcY4JlD8Efp6wAopqQAIoecHxCbiRUWULBevvW6wCzpUKA"}
Content-Type header MUST be set to application/jose+json.
If you don't have HTTP server configured, you can run the following
command on the target server (as root):
mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "vhDQ-ssP5mgMd27zpovkmSD7oV3sjhTKdO2AU5N9GMkUMNsQ612dIa1sxXGErrW9WGlOa8EkPeK2T4JA5IBUNnuxJBJfT-EmT3suH2uW8klbFlJqHDIAHbnVZjVcrqKFS4Iuub5oaG0wPT4hPe4IKR3vob7DL7Yv0sgHwFFD0N8VWDCb6kG5HUqyvvMr6x0sPOyPQEzzJO-YWUwZM-FQ-sXLfxkBsI9hz9EqfaxvGV3wUVY_OOKMbKcyCM0e_sa7Vrd0jg_FEgHLW2dFVe1wdLLW4YEiimNHwINVloZxQ4QrSAaGI-aXJx1FojPGpkLwviSTmMGGC2MD7BSVqIzjiQ"}}, "payload": "eyJ0bHMiOiBmYWxzZSwgInRva2VuIjogImFsOFozN2VQeGttczVqbzBXdHFndUxxMmFUN3NRRWRfUzFJdWJjRnpwd1UiLCAidHlwZSI6ICJzaW1wbGVIdHRwIn0", "signature": "LCNiHNdZheeLCEcNG3JStH6J3pTZHqWL3Zne5AkzuFJ5NM8UQrhpAE-ie8E5VeXEGvXZFlJOpKU72rDmlaBQIyrWF1NLHh1A9vbTdPf_xa1lwVvASAFnvgcUU0c7o--5BegP4GEeWHkeOpqi5s45f-ktNUxtPuY9KrK_ByEQdcwfTcaUGwgOy86Oy-zVfyU45K6e-7fGahXLmrmcG9ADf4EQFVAx6Kax42kTkGl9oS-IiitQcCkc7pZA8nDWG_D6f5u01bBvBOn4PewBauajBr5fOX1StIi4ealnDKq0mcY4JlD8Efp6wAopqQAIoecHxCbiRUWULBevvW6wCzpUKA"}' > .well-known/acme-challenge/al8Z37ePxkms5jo0WtqguLq2aT7sQEd_S1IubcFzpwU
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue
Първият вариант ми се стори по-приятен, въпреки великата глупост, че трябва на ръка да се зададе в конфигурацията на web сървъра какъв content type трябва да има дадения файл. За нещастие, по някаква причина не сработи при мен и се наложи да прибягна до втория вариант.
Втория вариант проработи за един домейн, но не и ако бях задал два – petko.me www.petko.me.
За всяко ново изпълнение на letsencrypt-auto се генерира нов (2048-битов!) частен ключ. Няма очевиден начин за увеличаване на големината на ключа или да указване на вече съществуващ такъв. След ровене открих, че има --csr параметър, който обаче при мен не проработи.
В крайна сметка според мен letsencrypt-autoне трябва да бъде използван.
Алтернативен инструмент
В крайна сметка изискванията ми са следните:
Искам сертификат, подписан от Let’s Encrypt
Искам да преизползвам частния ключ на сегашния си сертификат, за да не отрежа достъпа на клиентите (имам конфигуриран HPKP)
Искам да ми бъде върнат подписания сертификат като текст, с който да работя, както сметна за добре
Не искам да изпълнявам каквото и да е като root
Не искам да инсталирам излишни пакети
Предосатвеният от Let’s Encrypt инструмент не успя да отговори на изискванията ми. За щастие попаднах на https://github.com/diafygi/letsencrypt-nosudo. Със скрипта от това репо и с долния модифициран шелскрипт (разчита key.pem и openssl.cnf да са в работната директория), успях да се сдобия с подписан сертификат за petko.me и www.petko.me.
#!/bin/sh
# This script generates a simple SAN CSR to be used with Let's Encrypt
# CA. Mostly intended for "auth --csr" testing, but, since it's easily
# auditable, feel free to adjust it and use it on your production web
# server.
if [ "$#" -lt 1 ]
then
echo "Usage: $0 domain [domain...]" >&2
exit 1
fi
domains="DNS:$1"
shift
for x in "$@"
do
domains="$domains,DNS:$x"
done
SAN="$domains" openssl req -config "${OPENSSL_CNF:-openssl.cnf}" \
-new -nodes -subj '/' -reqexts san \
-key key.pem \
-out "${CSR_PATH:-csr.der}" \
-outform DER
echo "You can now run: letsencrypt auth --csr ${CSR_PATH:-csr.der}"