> Hi, > > thanks for the samples I will give it a try but wondering why > acme-client still works even httpd is not serving any kind of > location for a challenge exchange?
acme_client(1) is only working if a file could be created within a directory accessible by a locally-run web server. > Like I said I stoped httpd > intirely and still got a new certificate with acme-client. if you really stopped httpd and there is still something listening then there is another webserver process running. You can check locally with netstat(1) or 'ps -aux' or you can do 'curl -i http://your_domain/.well-known/acme-challenge' from another machine and look in the header which servername is answering this request. > But if it works as expected after a apply the suggested changes Im > okay with it :) I think it´s not a good idea to say "if it works, it´s okay for me...". At the moment you have a internet facing box that is listening on a port but you don´t know which process it is nor what it does. This is a serious security risk and I suggest you to investigate. > > regards > > Markus > > Am 16.03.2018 um 08:42 schrieb Florian Obser: > > > > this works for me: > > > > server "tlakh.xyz" { > > listen on 0.0.0.0 tls port 443 > > listen on :: tls port 443 > > tls certificate "/etc/ssl/tlakh.xyz.crt" > > tls key "/etc/ssl/private/tlakh.xyz.key" > > hsts > > location "/shop.6.html" { > > block return 402 > > } > > location "/coffee.6.html" { > > block return 418 > > } > > location "/.well-known/acme-challenge/*" { > > root "/acme" > > root strip 2 > > } > > } > > server "tlakh.xyz" { > > listen on 0.0.0.0 port 80 > > listen on :: port 80 > > hsts > > block return 302 "https://$HTTP_HOST$REQUEST_URI"; > > } > > > > > > On Thu, Mar 15, 2018 at 11:01:42AM +0100, Markus Rosjat wrote: > >> Hi there, > >> > >> Im kinda confused right now about it. I have a OpenBSD 6.1 running > >> a simple httpd.conf with a definition for a http server and a > >> https server so far so good, I figured I need to have a http > >> server so acme-client can talk to let's encrypt an issue > >> certificate requests also no big problem but now it get confusing. > >> I tried to automate the certificate renew and as far as I > >> understand the docs httpd.conf get evaluated to to bottom with > >> first matching rule found. So this would mean a definition like: > >> > >> $ext_addr ="*" # its just one nic with one external ip on that vm > >> > >> server "mydomain.tld" { > >> listen on $ext_addr port http > >> > >> location "/.well-known/acme-challenge/*" { > >> root "/acme" > >> root strip 2 > >> directory no auto index > >> } > >> > >> block return 302 "https://$HTTP_HOST$REQUEST_URI"; > >> } > >> > >> should enable acme-client to renew certificates but redirect other > >> traffic to the https server. Well it doesn't ! So I need to > >> comment out the block request to renew the certificate. That's a > >> thing I could live with and just invent some script that loads a > >> different conf file just for the renew and when the certificate is > >> obtained just load the normal httpd.conf and restart httpd. I was > >> playing arround and stumbled over the fact that acme-client > >> suddenly can renew certificates even without running httpd in the > >> first place o.O Thats just wrong since there isn't support that > >> does dns-01 challenges right? I stoped httpd to checked the site > >> wasn't reachable and did a > >> > >> acme-client -vvF mydomain.tld > >> > >> it gave me a new certificate from let's encrypt ... > >> > >> > >> anyway can someone who has the insight please tell me whats goin > >> on here and maybe post a config example that works for a basic > >> https redirect? Or is it really the case that I need to load a > >> config that hasn't a blok return statement in the http server > >> definition? > >> > >> One last note, I did a syspatch today and don't know if this > >> changed something in the behaviour of the components involved. > >> > >> regards > >> > >> -- > >> Markus Rosjat fon: +49 351 8107223 mail: [email protected] > >> > >> G+H Webservice GbR Gorzolla, Herrmann > >> Königsbrücker Str. 70, 01099 Dresden > >> > >> http://www.ghweb.de > >> fon: +49 351 8107220 fax: +49 351 8107227 > >> > >> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! > >> Before you print it, think about your responsibility and > >> commitment to the ENVIRONMENT > >> > > >
