Limiting Zone-Level Authenticated Origin Pulls on Apache

Configure the origin for Authenticated Origin Pulls (AOP) by adding directives to the Apache config:

SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /path/to/origin-pull-ca.pem

But, I run a shared hosting server, where most clients don’t use Cloudflare. I presume, that if SSLVerifyClient is set to require then domains on the server that communicate with clients other than Cloudflare will get an error. Is that right?

So the option is to restrict the SSLVerifyClient directive only to domains that talk to Cloudflare. We can do that by using <Directory> or <VirtualHost> containers, like this:

<Directory /home/user/public_html>
    SSLVerifyClient require
</Directory>

<VirtualHost 1.1.1.1:443>
    SSLVerifyClient require
</VirtualHost>

The rest of the directives on the other hand can be placed without a container so they are forced on the entire server:

SSLVerifyDepth 1
SSLCACertificateFile /path/to/origin-pull-ca.pem

Is this valid?

Also, for :grey: DNS records of domains with enabled AOP you would want to set SSLVerifyClient to none or just use hostname-level AOP and exclude the :grey: records.

I just put all 3 lines into the virtualhost container for the domains as I use a different certificate for each domain, so that works fine for defining different behaviour for different hosts (including not including anything for hosts that don’t need it).

SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /path/to/origin-pull-ca.pem
2 Likes

What about the :grey: records? Am I right about them?

Also, do you control your config file? The thing is that cPanel on my server locks it and only always include files to it. This is tricky because when Apache finds the first vhost match it ignores other matches for that host. So I have to remap the entire vhost’s code in my include file just to add my directives, which is not a good practice.

That is why <Directory> is a better option for me. I hope it works, I’m going to test it out soon.

How do you acquire and generate those certs? Are those self-signed, is it OK for them to be self-signed or are these CA-issued?

Also, these are different from the edge and origin certs, right? Can you share your procedure for AOP certs?

Yes, certificates are self-signed.

Create them as here…

Enable origin pulls in the dashboard, here…
https://dash.cloudflare.com/?to=/:account/:zone/ssl-tls/origin

Then you need to use the API to upload the certificate…

Use this to list the certificates (to check before and after). Note that only one certificate can be added at a time so you will need to delete one before uploading another.

curl --request GET \
  --url https://api.cloudflare.com/client/v4/zones/xxxxxxxxxxxxxxxxx/origin_tls_client_auth \
  --header "X-Auth-Email: [email protected]" \
  --header "X-Auth-Key: xxxxxxxxxxxxxxxxxxxx"

Use this to upload the certificate…

curl --request POST \
  --url https://api.cloudflare.com/client/v4/zones/xxxxxxxxxxxxxxx/origin_tls_client_auth \
  --header 'Content-Type: application/json' \
  --header "X-Auth-Email: [email protected]" \
  --header "X-Auth-Key:xxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
  --data '{
  "certificate": "-----BEGIN CERTIFICATE-----\n.......(the cert).........\n-----END CERTIFICATE-----\n",
  "private_key": "-----BEGIN PRIVATE KEY-----\n......(the key).......\n-----END PRIVATE KEY-----\n"
}'

Use this to enable the certificate…

curl --request PUT \
  --url https://api.cloudflare.com/client/v4/zones/xxxxxxxxxxxxxxxx/origin_tls_client_auth/settings \
  --header "X-Auth-Email: [email protected]" \
  --header "X-Auth-Key: xxxxxxxxxxxxxxxxxxxx" \
  --data '{
  "enabled": true
}'
1 Like

Wow! Thank you! I have the option in cPanel to generate certs and keys, will that suffice instead of manually creating like in the article you posted?

Also, can you comment about :grey: records?

Records that aren’t proxied won’t go through Cloudflare so won’t have the certificate and will fail if you try to connect.

We use a different host name for direct access to the origin (over WARP and a tunnel), all public internet access is restricted to be via Cloudflare.

3 Likes

I tried to get path based mTLS working some year ago. My recollection is that it would not work, and I believe with TLS1.3 is even less likely to work. mTLS authentication happens during the initial ClientHello/ServerHello handshake. The directives in a Directory context do not apply during the initial client exchange, so will not have the effect you are seeking.

2 Likes

Bad news then. So vhosts are my only option. I will investigate how to add directives without replicating the entire default vhost.

Sorry, yes. Just double checked our config and the differing certificates are applied to different IPv6 addresses, probably for that reason.

1 Like

What happens if you set up your origin to require mTLS but disable Cloudflare’s Authenticate Origin Pulls setting? Then no one can access your server?

Correct.

1 Like

You recommended creating a client cert for origin pulls using OpenSSL.

I have the option of generating a self-signed cert and key inside the cPanel interface. Will that be OK for this purpose?

Also, I’m confused about what domains to cover in the cert, since this cert will be uploaded to the client, Cloudflare in this case. Is there a need to list other info in the cert like organization, etc.?

OK, now I’m completely lost even after reading the documentation:

I have a Let’s Encrypt SSL cert at my origin and I enabled Cloudflare’s Edge Universal SSL cert. These have nothing to do with mTLS certs, right?

For mTLS (Authenticated Origin Pulls) both my server and the client must have certs? One of them is the Cloudflare’s cert which I’m required to upload to my server and define the path to it. The other one I need to create and upload to Cloudflare via API.

That way, my server will present Cloudflare’s cert to Cloudflare and Cloudflare will present my server’s cert to my server, in a way proving the authenticity of the collaboration. Is it possible for just one side to use the cert authentication, but the other?

What does enabling Authenticated Origin Pulls enable - Cloudflare’s check for its certificate on my server?

Can you please help me clarify the basic functioning here?

MTLS is not authenticated origin pulls. Mutual TLS is between the client and the (edge). Authenticated origin pulls are between between Cloudflare and the origin.

What are you trying to achieve?

2 Likes

There are four different things here, two Client Authentications, and two Server Authentications.

User ↔ Cloudflare ↔ Origin

  1. The User looks at the Cloudflare edge certificate to confirm that it is talking to the correct server. This is done using Universal SSL, Advanced Certificate Manager, or Custom Certificates.

  2. Cloudflare can look at the certificate presented by your Origin to prove that it is talking to the correct origin. This is the Full (Strict) mode of SSL. (If you enable just Full SSL, without strict, no identity verification takes place). This requires that you have a valid certificate on your Origin, which can be either a normal certificate such as one from Let’s Encrypt, or a Cloudflare Origin Certificate.

  3. The Origin can require that Cloudflare present a client certificate so that the Origin knows it is talking to Cloudflare (and potentially that it is talking to the correct account in Cloudflare depending on your configuration). This is Authenticated Origin Pull.

  4. Finally, you can configure mTLS, so that Users need to prove their identity before they can talk to the Cloudflare Edge.

1 and 2 are table stakes, and every property on Cloudflare should have those configured. 3 involves a bit more work, but is relatively straightforward. 4 is really for specific use cases, you would not configure mTLS for a general purpose website as you need much more control over the clients than you will ever have for a public facing website.

Yes. In fact, that is how most of the Internet behaves today. When I visit community.cloudflare.com my browser verifies that it is talking to the correct server using Server Authentication (1 above). But my browser does not perform any Client Authentication to prove who I am (4 above). In general, you must do Server Authentication on a connection before you can look at Client Authentication.

4 Likes

Thank you for the answer! Sorry for this delay, I will respond as soon as I can.

1 Like

The issue I have is configuring my origin for AOP due to the nature of how cPanel locks the main Apache config file for editing. You can apply edits via files that are included in the various locations of the main config file.

But some of those include locations are not working so I’m talking to the cPanel crew about figuring this out. For example, I run a shared hosting server with customers that don’t use Cloudflare so I need to limit the AOP handshake to my account’s domains only.

As soon as I solve this, I’ll get back to you. Thank you for staying with me.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.