acme-client(1) and http_proxy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

acme-client(1) and http_proxy

Manuel Giraud-4
Hi,

I'm trying to use the new acme-client on a server behind a corporate
proxy (i.e. I have to set a http_proxy to get out). It seems (from
reading the code) that acme-client(1) does not honor http_proxy.

Is this on purpose? If so, can someone point me to another acme client
that does this?
--
Manuel Giraud

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

athompso
By definition, you will (probably) not be able to use the ACME protocol - it only works (normally) when your system is connected directly to the public internet with a static IP address.

Simply because you say "behind a corporate firewall", I already know (or at least assume) that ACME will not work for you, ever.

ACME, and LetsEncrypt, only handles public websites.  There are ways around this, but they are painful and likely not worthwhile - it *will* be cheaper to just buy a regular SSL certificate than to get a LetsEncrypt certificate for an internal server.

-Adam

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Manuel Giraud
> Sent: April 21, 2017 07:37
> To: [hidden email]
> Subject: acme-client(1) and http_proxy
>
> Hi,
>
> I'm trying to use the new acme-client on a server behind a corporate
> proxy (i.e. I have to set a http_proxy to get out). It seems (from reading
> the code) that acme-client(1) does not honor http_proxy.
>
> Is this on purpose? If so, can someone point me to another acme client
> that does this?
> --
> Manuel Giraud


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Stuart Henderson
In reply to this post by Manuel Giraud-4
On 2017-04-21, Manuel Giraud <[hidden email]> wrote:
> Hi,
>
> I'm trying to use the new acme-client on a server behind a corporate
> proxy (i.e. I have to set a http_proxy to get out). It seems (from
> reading the code) that acme-client(1) does not honor http_proxy.
>
> Is this on purpose? If so, can someone point me to another acme client
> that does this?

Most other acme clients do work through a proxy - use whatever fits your
needs best..


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Stuart Henderson
In reply to this post by athompso
On 2017-04-25, Adam Thompson <[hidden email]> wrote:

> By definition, you will (probably) not be able to use the ACME
> protocol - it only works (normally) when your system is connected
> directly to the public internet with a static IP address.
>
> Simply because you say "behind a corporate firewall", I already know
> (or at least assume) that ACME will not work for you, ever.
>
> ACME, and LetsEncrypt, only handles public websites. There are ways
> around this, but they are painful and likely not worthwhile - it
> *will* be cheaper to just buy a regular SSL certificate than to get a
> LetsEncrypt certificate for an internal server.

Fake news :)

Firstly, with dns-01 challenge you can get a certificate for a server
which doesn't allow external access at all (the request and challenge
can be done with completely separate machines than the certificate
is for).

Secondly, some environments permit inbound connections but require
a proxy for outbound access from a DMZ. In a hosting environment,
restricting outbound access is often more important than inbound.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

athompso
On 2017-04-25 05:27, Stuart Henderson wrote:

> On 2017-04-25, Adam Thompson <[hidden email]> wrote:
>> By definition, you will (probably) not be able to use the ACME
>> protocol - it only works (normally) when your system is connected
>> directly to the public internet with a static IP address.
>>
>> Simply because you say "behind a corporate firewall", I already know
>> (or at least assume) that ACME will not work for you, ever.
>>
>> ACME, and LetsEncrypt, only handles public websites. There are ways
>> around this, but they are painful and likely not worthwhile - it
>> *will* be cheaper to just buy a regular SSL certificate than to get a
>> LetsEncrypt certificate for an internal server.
>
> Fake news :)

Ha!  That made me laugh!
I was deliberately omitting all the details of the other challenge
protocols, because (see below).  But yes, I deliberately sacrificed
correctness for utility in my response.

> Firstly, with dns-01 challenge you can get a certificate for a server
> which doesn't allow external access at all (the request and challenge
> can be done with completely separate machines than the certificate
> is for).
>
> Secondly, some environments permit inbound connections but require
> a proxy for outbound access from a DMZ. In a hosting environment,
> restricting outbound access is often more important than inbound.

While it's possible that this was the case, the fact the OP was even
asking the question in the first place strongly suggests that this is
not his situation.

I stand by my statement that just buying a cheap SSL cert will, for
anything other than the simple case of an online, directly-connected,
webserver, be cheaper than the labour required to obtain a LetsEncrypt
certificate.

 From what I've read so far, you'd have to be *really* committed to
LetsEncrypt to go to the bother of using any of the alternate challenge
protocols.  In all the situations where one person could complete the
process themselves, that person is highly likely to simply be directly
connected anyway - so why bother?

Once the entire CA industry moves towards ACME (if that happens) then I
can see a number of situations where those alternate challenge protocols
will be useful and/or required, but for a LetsEncrypt certificate?  It
just doesn't seem worthwhile.  Especially when the cost of a
single-hostname SSL cert (which meets the needs of many users) is now
somewhere below US$5/year!

And neither of us addressed the fact that for a server that's "behind a
corporate firewall", there's a good chance that it's not even using a
legit gTLD/ccTLD, which means getting an external domain-validated SSL
cert for it will be (or should be!) impossible in the first place.

-Adam

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Predrag Punosevac-2
In reply to this post by Manuel Giraud-4
Adam Thompson wrote:

> I stand by my statement that just buying a cheap SSL cert will, for
> anything other than the simple case of an online, directly-connected,
> webserver, be cheaper than the labour required to obtain a LetsEncrypt
> certificate.

A cheap certificate like the one you can buy from GoDaddy will trigger
browser exception warning just like the self-signed certificates. If the
your goal is to encrypt web traffic self-signed certificate will do it.
If your goal is to provide a peace of mind to your customers by
presenting them a proper SSL certificate which will authenticate against
credible third party server I am afraid that you will have to shell
little bit more money to get the one from Verisign.

LetsEncrypt is a wonderful option for people like me who need to have
both (encryption and authentication) but without resources (working for
an academic Lab) to pay for a real certificate.

Best,
Predrag

P.S. In all my years on this mailing list I have seen nothing but the
most insightful, helpful, and polite answers by Mr. Stuart Henderson.
If he had labeled my post as a "Fake news :)" I would reflect on it
before posting again in the same thread.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Stefan Wollny-2
Gesendet: Mittwoch, 26. April 2017 um 06:16 Uhr
Von: "Predrag Punosevac" <[hidden email]>
An: [hidden email]
Betreff: Re: acme-client(1) and http_proxy
[ ... ]
> Best,
> Predrag
>
> P.S. In all my years on this mailing list I have seen nothing but the
> most insightful, helpful, and polite answers by Mr. Stuart Henderson.
+1

> If he had labeled my post as a "Fake news :)" I would reflect on it
> before posting again in the same thread.
Words of wisdom here

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

thank you sthen@ [Was: Re: acme-client(1) and http_proxy]

Marcus MERIGHI
To keep him going I suggest:

http://spacehopper.org/wishlist

"Exploding the phone" is taken.
("Estimated delivery:  23 May 2017 - 16 Jun. 2017")

We all benefit :-)

Marcus

[hidden email] (Stefan Wollny), 2017.04.26 (Wed) 10:04 (CEST):

> Gesendet:??Mittwoch, 26. April 2017 um 06:16 Uhr
> Von:??"Predrag Punosevac" <[hidden email]>
> An:??[hidden email]
> Betreff:??Re: acme-client(1) and http_proxy
> [ ... ]
> > Best,
> > Predrag
> >
> > P.S. In all my years on this mailing list I have seen nothing but the
> > most insightful, helpful, and polite answers by Mr. Stuart Henderson.
> +1
>
> > If he had labeled my post as a "Fake news :)" I would reflect on it
> > before posting again in the same thread.
> Words of wisdom here
>
> !DSPAM:590054a628014500718621!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Stuart Henderson
In reply to this post by athompso
On 2017-04-25, Adam Thompson <[hidden email]> wrote:

> On 2017-04-25 05:27, Stuart Henderson wrote:
>
>> Firstly, with dns-01 challenge you can get a certificate for a server
>> which doesn't allow external access at all (the request and challenge
>> can be done with completely separate machines than the certificate
>> is for).
>>
>> Secondly, some environments permit inbound connections but require
>> a proxy for outbound access from a DMZ. In a hosting environment,
>> restricting outbound access is often more important than inbound.
>
> While it's possible that this was the case, the fact the OP was even
> asking the question in the first place strongly suggests that this is
> not his situation.
>
> I stand by my statement that just buying a cheap SSL cert will, for
> anything other than the simple case of an online, directly-connected,
> webserver, be cheaper than the labour required to obtain a LetsEncrypt
> certificate.
>
>  From what I've read so far, you'd have to be *really* committed to
> LetsEncrypt to go to the bother of using any of the alternate challenge
> protocols.

It's not that hard with some clients, especially with DNS hosted at
a provider that has an API that the client already supports (or with
nsupdate).

If it's a one-off, I agree a cheap SSL cert is often easier. But the
work that's involved is manual and needs doing at renewal (generate
key/csr, get payment approval, login to CA's website, order, enter
card details, manually handle CA's DNS/email auth, copy cert into
place, figure out which chain certs are needed if the CA changed
them, fix things if you messed up with the keys). Multiply that by
a few domains, especially when they need renewing at different
times, and it gets to be a real pain. More so when browsers push
harder and the validity of certs gets reduced in length across the
board.

So with LetsEncrypt and especially non-http challenges it's often
more of a faff to setup initially, but that's once only, amortised
across multiple domains, in theory the only thing you're likely to
need to do later is update the agreement URL.

(And you don't have to worry about unscrupulous registrars trying
to rip you off by autorenewing at several times the usual cost,
hi g*d***y).

> In all the situations where one person could complete the
> process themselves, that person is highly likely to simply be directly
> connected anyway - so why bother?

I usually only let webservers connect out to specific IPs, which doesn't
work for connecting to letsencrypt's API servers, currently on akamai
and moving around. Punting the requests to a proxy lets you to restrict
by domain name on the proxy instead.

> Once the entire CA industry moves towards ACME (if that happens) then I
> can see a number of situations where those alternate challenge protocols
> will be useful and/or required, but for a LetsEncrypt certificate?  It
> just doesn't seem worthwhile.  Especially when the cost of a
> single-hostname SSL cert (which meets the needs of many users) is now
> somewhere below US$5/year!
>
> And neither of us addressed the fact that for a server that's "behind a
> corporate firewall", there's a good chance that it's not even using a
> legit gTLD/ccTLD, which means getting an external domain-validated SSL
> cert for it will be (or should be!) impossible in the first place.

It may well be "www.$somecompany.com" on a DMZ behind a corporate
firewall.

And/or it may be run on multiple machines for failover and need the
cert on all of them, here it's often more straightforward to do
the auth from a management host (dns challenge is really needed for
this) and push out the cert and keys across from config management.



* If you want to do dns-01 challenge with acme-client, you'll need to
use Kristaps' version for now, base acme-client only supports the
standard http challenge type. The UI isn't the simplest; use
'-t dns-01', then it outputs "dns-01 domainname token.key", then
you convert token.key into a suitable format for a DNS TXT record:
  "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _"
Get the record to the nameserver, then send the whole "dns-01
domainname token.key" line back to acme-client, and cross fingers.
If there are too many errors you'll lock yourself out for a period,
so test with the staging server first.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: thank you sthen@ [Was: Re: acme-client(1) and http_proxy]

Stuart Henderson
In reply to this post by Marcus MERIGHI
On 2017-04-26, Marcus MERIGHI <[hidden email]> wrote:
> To keep him going I suggest:
>
> http://spacehopper.org/wishlist
>
> "Exploding the phone" is taken.
> ("Estimated delivery:  23 May 2017 - 16 Jun. 2017")
>
> We all benefit :-)

Thanks!  I haven't updated that list recently so it's a bit random at the moment :-)


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Jeff Ross
In reply to this post by Stuart Henderson
On 4/26/17 11:02 AM, Stuart Henderson wrote:

> On 2017-04-25, Adam Thompson <[hidden email]> wrote:
>> On 2017-04-25 05:27, Stuart Henderson wrote:
>>
>>
>> * If you want to do dns-01 challenge with acme-client, you'll need to
>> use Kristaps' version for now, base acme-client only supports the
>> standard http challenge type. The UI isn't the simplest; use
>> '-t dns-01', then it outputs "dns-01 domainname token.key", then
>> you convert token.key into a suitable format for a DNS TXT record:
>>    "echo -n token.key | sha256 -b | tr -d = | tr + - | tr / _"
>> Get the record to the nameserver, then send the whole "dns-01
>> domainname token.key" line back to acme-client, and cross fingers.
>> If there are too many errors you'll lock yourself out for a period,
>> so test with the staging server first.
>>
>>
I haven't seen anyone mention acme.sh yet--a shell script for
letsencrypt with no external dependencies.

https://github.com/Neilpang/acme.sh

It was trivial for me to write a dns api script for djbdns--very handy
to have to bootstrap a new domain without previously setting up http in
apache2 first.

I'd send that out to anyone interested--ask me off list.

Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Theo de Raadt-2
> I haven't seen anyone mention acme.sh yet--a shell script for
> letsencrypt with no external dependencies.
>
> https://github.com/Neilpang/acme.sh

No external dependencies, and no security foundations.

No privsep, no clear seperation.

Using pretty much every unsafe pattern tied to security holes in the past.

Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read
the libressl one, go read upstream openssl command source.

No attempt at security.

Just doing the job, and assuming every mistake later can be  

It's like constructing jetliners from foundational components, and by
that I mean sticks and stones.

I'm sorry, but I don't get it.  It is crazy to recommend something
that hasn't been STUDIED to ensure it dutifully tries to only perform
the task and creates no new risk.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Jeff Ross
On 4/26/17 12:41 PM, Theo de Raadt wrote:

>> I haven't seen anyone mention acme.sh yet--a shell script for
>> letsencrypt with no external dependencies.
>>
>> https://github.com/Neilpang/acme.sh
> No external dependencies, and no security foundations.
>
> No privsep, no clear seperation.
>
> Using pretty much every unsafe pattern tied to security holes in the past.
>
> Using the openssl command *GO READ THAT CODE SOMETIME*, don't go read
> the libressl one, go read upstream openssl command source.
>
> No attempt at security.
>
> Just doing the job, and assuming every mistake later can be
>
> It's like constructing jetliners from foundational components, and by
> that I mean sticks and stones.
>
> I'm sorry, but I don't get it.  It is crazy to recommend something
> that hasn't been STUDIED to ensure it dutifully tries to only perform
> the task and creates no new risk.
>
Always good to hear from you, Theo!

acme.sh does not require root/sudoer access.  For sure I run it as an
unprivileged user and hope you do as well!

Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Theo de Raadt-2
> acme.sh does not require root/sudoer access.  For sure I run it as an
> unprivileged user and hope you do as well!

The concept of privsep isn't about running as an unprivileged user.

It is so much more.

The problem is that unprivileged users still have the full system call
interface available to them.  Ignoring that reality -- in these trying
times -- is like living in a cave.

Don't care where you run such software.  But suggesting it to others
as a quality choice is irresponsible.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: acme-client(1) and http_proxy

Stuart Henderson
In reply to this post by Predrag Punosevac-2
On 2017-04-26, Predrag Punosevac <[hidden email]> wrote:
> Adam Thompson wrote:
>
>> I stand by my statement that just buying a cheap SSL cert will, for
>> anything other than the simple case of an online, directly-connected,
>> webserver, be cheaper than the labour required to obtain a LetsEncrypt
>> certificate.
>
> A cheap certificate like the one you can buy from GoDaddy will trigger
> browser exception warning just like the self-signed certificates.

They all work just as well as each other unless you have requirements to
support unusual/old clients. Just make sure your server has any necessary
chain certificates as well as the server certificate. Run the ssllabs
checker after setting up (or try connecting with a command-line client),
some browsers hide this problem.

GoDaddy are about 10x too expensive, try ssls.com


Loading...