Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #5111 > unrolled thread

seltsames Verhalten mit acme_tiny.py, wie löse ich es?

Back to article view | Back to de.comp.lang.python

Contents

  seltsames Verhalten mit acme_tiny.py, wie löse ich es? "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2018-01-31 18:33 +0100
    Re: seltsames Verhalten mit acme_tiny.py, wie löse ich es? "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-01-31 21:49 +0100
      Re: seltsames Verhalten mit acme_tiny.py, wie löse   ich es? "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2018-02-01 05:44 +0100

#5111 — seltsames Verhalten mit acme_tiny.py, wie löse ich es?

Hallo,

ich verwende f. Let's Encrypt dieses
https://github.com/diafygi/acme-tiny
Script ...

mein Router hat - klarerweise - mehrere NICs, und er ist vollständig 
DualStack;

WANseitig ist es nun so, daß zwar sowohl der Zugriff über IPv4 und IPv6 
möglich ist, aber jeweils unter einem anderen DNS-Namen,

host.example.com f. IPv6
hostv4.example.com f. IPv4

dies deswegen, weil IPv6 ist fix und IPv4 ist dynamisch;
soweit so gut; und es sind 2 getrennte NameVirtual Hosts;

wenn ich nun mit diesem Skript das Zertifikat f. IPv6 erneuern will
kommt das ...

Parsing account key...
Parsing CSR...
Registering account...
Already registered.
Verifying host.ipv6home.eu...
Traceback (most recent call last):
   File "./acmetiny.py", line 198, in <module>
     main(sys.argv[1:])
   File "./acmetiny.py", line 194, in main
     signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, 
log=LOGGER, CA=args.ca)
   File "./acmetiny.py", line 123, in get_crt
     wellknown_path, wellknown_url))
ValueError: Wrote file to 
/var/www/inet/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY, 
but couldn't download 
http://host.example.com/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY

im Skript selbst habe ich folgendes gefunden, wenn ich diesen Teil hier

# check that the file is in place
wellknown_url = 
"http://{0}/.well-known/acme-challenge/{1}".format(domain, token)
  try:
        resp = urlopen(wellknown_url)
        resp_data = resp.read().decode('utf8').strip()
        assert resp_data == keyauthorization
  except (IOError, AssertionError):
        os.remove(wellknown_path)
        raise ValueError("Wrote file to {0}, but couldn't download 
{1}".format(wellknown_path, wellknown_url))

auskommentiere, dann klappt das; hingegen mit habe ich dieses Problem 
nicht; daher die Frage: woher kommt dieses Verhalten mit IPv6?
da es auch mit deaktivierter Firewall ist, wird es auch nicht durch
irgendeine Regel verursacht ...
(im Log des Apache sehe ich keine Zugriffe derart, sprich es wird vorher 
bereits blockiert)

ich habe kaum bis gar keine Pyrhon-Kenntnisse, aber ich nehme an,
daß dies mit dem urlopen im Zusammenhang steht;

ich hoffe es bringt jemand Licht ins Dunkel

Danke,
Walter H.

[toc] | [next] | [standalone]

#5112

On 2018-01-31 17:33, Walter H. <Walter.H-Nntp@mathemainzel.info> wrote:
> ich verwende f. Let's Encrypt dieses
> https://github.com/diafygi/acme-tiny
> Script ...
>
> mein Router hat - klarerweise - mehrere NICs, und er ist vollständig 
> DualStack;
[...]
> wenn ich nun mit diesem Skript das Zertifikat f. IPv6 erneuern will
> kommt das ...
>
> Parsing account key...
> Parsing CSR...
> Registering account...
> Already registered.
> Verifying host.ipv6home.eu...
> Traceback (most recent call last):
>    File "./acmetiny.py", line 198, in <module>
>      main(sys.argv[1:])
>    File "./acmetiny.py", line 194, in main
>      signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, 
> log=LOGGER, CA=args.ca)
>    File "./acmetiny.py", line 123, in get_crt
>      wellknown_path, wellknown_url))
> ValueError: Wrote file to 
> /var/www/inet/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY, 
> but couldn't download 
> http://host.example.com/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY

Hmm. Inkonsistent anonymisierte Hostnamen (einmal "host.ipv6home.eu",
einmal "host.example.com") sind kontraproduktiv. Da weiß man nicht, ob
die unterschiedlich sind, weil die Originalnamen auch unterschiedlich
waren, oder weil Du beim Anonymisieren schlampig warst. Wenn Dein Server
eine öffentliche IPv4-Adresse hat, ist es ohnehin sinnlos, den geheim
halten zu wollen. Die ersten Bots haben den sicher wenige Minuten,
nachdem er eingeschaltet wurde, entdeckt.


> im Skript selbst habe ich folgendes gefunden, wenn ich diesen Teil hier
>
> # check that the file is in place
> wellknown_url = 
> "http://{0}/.well-known/acme-challenge/{1}".format(domain, token)
>   try:
>         resp = urlopen(wellknown_url)
>         resp_data = resp.read().decode('utf8').strip()
>         assert resp_data == keyauthorization
>   except (IOError, AssertionError):
>         os.remove(wellknown_path)
>         raise ValueError("Wrote file to {0}, but couldn't download 
> {1}".format(wellknown_path, wellknown_url))
>
> auskommentiere, dann klappt das; hingegen mit habe ich dieses Problem 
> nicht; daher die Frage: woher kommt dieses Verhalten mit IPv6?
> da es auch mit deaktivierter Firewall ist, wird es auch nicht durch
> irgendeine Regel verursacht ...
> (im Log des Apache sehe ich keine Zugriffe derart, sprich es wird vorher 
> bereits blockiert)

Hast Du ein /etc/hosts, in dem host.example.com definiert ist? acme-tiny
versucht zuerst selbst, die Challenge zu überprüfen, bevor es die CA
bemüht. Das geht aber natürlich nur, wenn der Server vom gleichen
Rechner aus unter dem gleichen Namen erreichbar ist. Manche
Linux-Distributionen schreiben so Zeug wie "127.0.1.1 meinname" da rein.
Oder manchmal vergisst man, das nach einer Adressänderung zu editieren.
Das führt dann zu Effekten wie dem von Dir beobachteten (das hat mich
auch mal geraume Zeit gekostet).

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5113 — Re: seltsames Verhalten mit acme_tiny.py, wie löse ich es?

On 31.01.2018 21:49, Peter J. Holzer wrote:
> On 2018-01-31 17:33, Walter H.<Walter.H-Nntp@mathemainzel.info>  wrote:
>> ich verwende f. Let's Encrypt dieses
>> https://github.com/diafygi/acme-tiny
>> Script ...
>>
>> mein Router hat - klarerweise - mehrere NICs, und er ist vollständig
>> DualStack;
> [...]
>> wenn ich nun mit diesem Skript das Zertifikat f. IPv6 erneuern will
>> kommt das ...
>>
>> Parsing account key...
>> Parsing CSR...
>> Registering account...
>> Already registered.
>> Verifying host.ipv6home.eu...
>> Traceback (most recent call last):
>>     File "./acmetiny.py", line 198, in<module>
>>       main(sys.argv[1:])
>>     File "./acmetiny.py", line 194, in main
>>       signed_crt = get_crt(args.account_key, args.csr, args.acme_dir,
>> log=LOGGER, CA=args.ca)
>>     File "./acmetiny.py", line 123, in get_crt
>>       wellknown_path, wellknown_url))
>> ValueError: Wrote file to
>> /var/www/inet/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY,
>> but couldn't download
>> http://host.example.com/.well-known/acme-challenge/gkh9nE7F__wOulP6YOw8E0OS0qh-EJmUOpVLGcz22KY
>
> Hmm. Inkonsistent anonymisierte Hostnamen (einmal "host.ipv6home.eu",
> einmal "host.example.com") sind kontraproduktiv.
hatte ich übersehen ...

>> im Skript selbst habe ich folgendes gefunden, wenn ich diesen Teil hier
>>
>> # check that the file is in place
>> wellknown_url =
>> "http://{0}/.well-known/acme-challenge/{1}".format(domain, token)
>>    try:
>>          resp = urlopen(wellknown_url)
>>          resp_data = resp.read().decode('utf8').strip()
>>          assert resp_data == keyauthorization
>>    except (IOError, AssertionError):
>>          os.remove(wellknown_path)
>>          raise ValueError("Wrote file to {0}, but couldn't download
>> {1}".format(wellknown_path, wellknown_url))
>>
>> auskommentiere, dann klappt das; hingegen mit habe ich dieses Problem
>> nicht; daher die Frage: woher kommt dieses Verhalten mit IPv6?
>> da es auch mit deaktivierter Firewall ist, wird es auch nicht durch
>> irgendeine Regel verursacht ...
>> (im Log des Apache sehe ich keine Zugriffe derart, sprich es wird vorher
>> bereits blockiert)
>
> Hast Du ein /etc/hosts, in dem host.example.com definiert ist?

ja und nur mit einer IPv6 aber die Falsche, die richtige war nur im 
globalen DNS

> acme-tiny
> versucht zuerst selbst, die Challenge zu überprüfen, bevor es die CA
> bemüht.

das scheint genau dieser Teil zu sein, welcher nur mit IPv6 Probleme 
macht ...

> Das geht aber natürlich nur, wenn der Server vom gleichen
> Rechner aus unter dem gleichen Namen erreichbar ist.

ja genau hier hackt es,
ein
wget http://host.example.com/   klappt von jedem anderen Host, nicht 
aber von sich selbst ...
darum auch, wenn dieser Teil im Skript auskommentiert ist, geht es;

> Manche
> Linux-Distributionen schreiben so Zeug wie "127.0.1.1 meinname" da rein.
> Oder manchmal vergisst man, das nach einer Adressänderung zu editieren.
> Das führt dann zu Effekten wie dem von Dir beobachteten (das hat mich
> auch mal geraume Zeit gekostet).

Danke f. den Hinweis, genau das war es

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.python

csiph-web