Why port 587 not using self generated CA Certificate?

Before reporting a bug, please see our FAQ in FAQ.md!

Description

https://github.com/WhatsApp/proxy/blob/main/FAQ.md#5-does-the-proxy-support-https-or-socks

It is indicated here that this proxy is just passing TCP traffic around.
If that is the case, why need to generate a random CA Certificate?

Lines 25 to 47 in 2ea2f1f

    
           export RANDOM_SSL=$(head -c 60 /dev/urandom | tr -dc 'a-zA-Z0-9') 
        
           export SSL_SUBJECT="${RANDOM_SSL}.net" 
        
           export SSL_DNS=${SSL_DNS} 
        
           export SSL_IP=${SSL_IP} 
        
           export DEBUG=${DEBUG:=1} 
        
           echo "--> Certificate Authority" 
        
           echo "Generating certs for ${SSL_SUBJECT}" 
        
           if [[ -e ./${CA_KEY} ]]; then 
        
               echo "====> Using existing CA Key ${CA_KEY}" 
        
           else 
        
               echo "====> Generating new CA key ${CA_KEY}" 
        
               openssl genrsa -out ${CA_KEY} 4096 
        
           fi 
        
           if [[ -e ./${CA_CERT} ]]; then 
        
               echo "====> Using existing CA Certificate ${CA_CERT}" 
        
           else 
        
               echo "====> Generating new CA Certificate ${CA_CERT}" 
        
               openssl req -x509 -new -nodes -key ${CA_KEY} -days ${CA_EXPIRE} -out ${CA_CERT} -subj "/CN=${CA_SUBJECT}"  || exit 1 
        
           fi

Since a random CA Certificate is generated for port 443, why doesn't port 587 use this same CA Certificate but chooses to use the official WhatsApp one?

These 3 points are total contradictions and makes media fails in places that block WhatsApp. There is so much room to do better if the aim is to really help people get access to WhatsApp.

Failed Step

The use of offical WhatsApp cert makes media fails in places that block WhatsApp.

Yes, that’s the problem

@Nicepaul

@Nicepaul do you know of a workaround?

@Nicepaul

@Nicepaul do you know of a workaround?

I'm not deploying a WhatsApp proxy on a VPS; I'm setting it up on my home OpenWRT router to bypass issues with media not working. However, the prerequisite is that the OpenWRT router must be able to successfully bypass the firewall restrictions.

Does the proxy behave differently on different hardware?
The proxy has to be located outside the restricted network.

Does the proxy behave differently on different hardware? The proxy has to be located outside the restricted network.

This is not hardware-related. I’ve installed Passwall or SSRPlus on OpenWRT to bypass the Great Firewall of China, essentially setting up a VPN. All internal network applications and data, including WhatsApp, are routed through this tunnel, so the data packets are transmitted within the VPN and won’t be intercepted by the firewall. I’ve then mapped WhatsApp proxy's port to the public IP of the OpenWRT router. This is essentially a workaround to bypass WhatsApp’s certificate issues

I'm a little confused, if your mobile's WhatsApp is connected to the router which has VPN, why does it still need a proxy?

I'm a little confused, if your mobile's WhatsApp is connected to the router which has VPN, why does it still need a proxy?

I want to use WhatsApp but prefer not to install a VPN app on my phone. Therefore, setting up a WhatsApp proxy on my home OpenWRT router seems like a good solution. Additionally, VPNs tend to drain battery and can significantly affect phone network performance, making it impractical to keep them always on. However, turning it off would disrupt WhatsApp communication.

@eozturk1

ping @eozturk1

587 and 443 front different backends, with different cert requirements: https://github.com/WhatsApp/proxy/blob/main/proxy/src/proxy_config.cfg#L87

https://faq.whatsapp.com/1299035810920553/?helpref=uf_share

Since a random CA Certificate is generated for port 443, why doesn't port 587 use this same CA Certificate but chooses to use the official WhatsApp one?

I believe many are unable to connect directly to WhatsApp servers because they are being blocked actively
And blocking in this age is almost always more than just simple IP blocking
So much explanations, but no answers

still no solution?

443 is intended to unblock chat, while 587 fronts media on WA. These are configurable from inside the client, as traffic is distinguishable between them and we need to have different routes.If you'd like to game out another threat model, I'd encourage you to make a PR.

443 is intended to unblock chat, while 587 fronts media on WA. These are configurable from inside the client, as traffic is distinguishable between them and we need to have different routes.If you'd like to game out another threat model, I'd encourage you to make a PR.

How does that answer my question? Since a random CA Certificate is generated for port 443, why doesn't port 587 use this same CA Certificate but chooses to use the official WhatsApp one?

Because both paths are different. 443 fronts chat. 587 fronts media. Per the WhatsApp white paper (https://scontent.xx.fbcdn.net/v/t39.8562-6/455962147_1148247109601582_1673264986279156121_n.pdf?_nc_cat=101&ccb=1-7&_nc_sid=e280be&_nc_ohc=jJjOSDHnf5UQ7kNvwG8VXgy&_nc_oc=Adnc-fxOGUJbX9yFtP5mVIUP5S4LgHNuKrsx3JZ_6ghQ0kbtre0niq9X74NIvQhBnIY&_nc_zt=14&_nc_ht=scontent.xx&_nc_gid=yF2uFxWBNL3xzoK9sm9fiQ&oh=00_AfXkr_-k-uZ5yDTC8mB-9Z1ZwMt5go0tPTw-CStNRX6L_w&oe=68A8F899), we use noise pipes as the transport layer security for chat, but media is loaded separately. I’d encourage you to make a PR to try out the effectiveness of 587 using a self signed CA.

…

On 18 Aug 2025, at 8:59, bilogic wrote: bilogic left a comment (WhatsApp/proxy#303) > 443 is intended to unblock chat, while 587 fronts media on WA. These > are configurable from inside the client, as traffic is > distinguishable between them and we need to have different routes.If > you'd like to game out another threat model, I'd encourage you to > make a PR. How does that answer my question? `Since a random CA Certificate is generated for port 443, why doesn't port 587 use this same CA Certificate but chooses to use the official WhatsApp one?` -- Reply to this email directly or view it on GitHub: #303 (comment) You are receiving this because you commented. Message ID: ***@***.***>

Well, quite clearly, we have trouble understanding each other.

First, https://github.com/WhatsApp/proxy/blob/main/proxy/src/proxy_config.cfg#L87 - yes I know it's port 587, but I don't see any cert requirements... My SMTP port uses the same SSL cert as my HTTPS, so I can't make any sense of this.
Then comes the threat model, this assumes I know the existing threat model (which I don't). How does a proxy mitigate threats apart from obscuring its original source host, which is mooted by the use of unconfigurable cert with whatsapp in its CN?
Then it is mentioned both paths are different... are you saying they can't use the same cert because of that? How does this makes any sense.

At this point, it's probably easier to just say nobody knows why 587 chooses to the original cert from the source host.

Each port serves a different path. 443 is serves noise pipes traffic wrapped in TLS. 587 serves media traffic out of WhatsApp CDNs (http, not noise). These have different cert auth methods. I'm not sure how to be clearer than that. -- PeixianOn Aug 18, 2025, at 09:51, bilogic ***@***.***> wrote:bilogic left a comment (WhatsApp/proxy#303) Well, quite clearly, we have trouble understanding each other. First, https://github.com/WhatsApp/proxy/blob/main/proxy/src/proxy_config.cfg#L87 - yes I know it's port 587, but I don't see any cert requirements... My SMTP port uses the same SSL cert as my HTTPS, so I can't make any sense of this. Then comes the threat model, this assumes I know the existing threat model (which I don't). How does a proxy mitigate threats apart from obscuring its original source host, which is mooted by the use of unconfigurable cert with whatsapp in its CN? Then it is mentioned both paths are different... are you saying they can't use the same cert because of that? How does this makes any sense. At this point, it's probably easier to just say nobody knows why 587 chooses to the original cert from the source host. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

Ok...

Where are the "different cert auth methods" documented?
https://scontent.xx.fbcdn.net/v/t39.8562-6/455962147_1148247109601582_1673264986279156121_n.pdf?_nc_cat=101&ccb=1-7&_nc_sid=e280be&_nc_ohc=jJjOSDHnf5UQ7kNvwG8VXgy&_nc_oc=Adnc-fxOGUJbX9yFtP5mVIUP5S4LgHNuKrsx3JZ_6ghQ0kbtre0niq9X74NIvQhBnIY&_nc_zt=14&_nc_ht=scontent.xx&_nc_gid=yF2uFxWBNL3xzoK9sm9fiQ&oh=00_AfXkr_-k-uZ5yDTC8mB-9Z1ZwMt5go0tPTw-CStNRX6L_w&oe=68A8F899 I cannot find any "cert" word in this file

Again, noise does not require TLS. HTTPS (obviously) does require it. Noise can be optionally wrapped in TLS frames, which do not required cert validation. Chat messages are delivered via noise (optionally TLS). Media is always delivered over HTTPS, so a trusted cert authority is required. I would suggest reading through the noise pipes section and the media section on the white paper. -- PeixianOn Aug 18, 2025, at 12:22, bilogic ***@***.***> wrote:bilogic left a comment (WhatsApp/proxy#303) Ok... Where are the "different cert auth methods" documented? https://scontent.xx.fbcdn.net/v/t39.8562-6/455962147_1148247109601582_1673264986279156121_n.pdf?_nc_cat=101&ccb=1-7&_nc_sid=e280be&_nc_ohc=jJjOSDHnf5UQ7kNvwG8VXgy&_nc_oc=Adnc-fxOGUJbX9yFtP5mVIUP5S4LgHNuKrsx3JZ_6ghQ0kbtre0niq9X74NIvQhBnIY&_nc_zt=14&_nc_ht=scontent.xx&_nc_gid=yF2uFxWBNL3xzoK9sm9fiQ&oh=00_AfXkr_-k-uZ5yDTC8mB-9Z1ZwMt5go0tPTw-CStNRX6L_w&oe=68A8F899 I cannot find any "cert" word in this file —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

Navigation Menu

Repository navigation

Why port 587 not using self generated CA Certificate? #303

Description

Failed Step

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	export RANDOM_SSL=$(head -c 60 /dev/urandom \| tr -dc 'a-zA-Z0-9')
	export SSL_SUBJECT="${RANDOM_SSL}.net"
	export SSL_DNS=${SSL_DNS}
	export SSL_IP=${SSL_IP}

	export DEBUG=${DEBUG:=1}

	echo "--> Certificate Authority"
	echo "Generating certs for ${SSL_SUBJECT}"

	if [[ -e ./${CA_KEY} ]]; then
	echo "====> Using existing CA Key ${CA_KEY}"
	else
	echo "====> Generating new CA key ${CA_KEY}"
	openssl genrsa -out ${CA_KEY} 4096
	fi

	if [[ -e ./${CA_CERT} ]]; then
	echo "====> Using existing CA Certificate ${CA_CERT}"
	else
	echo "====> Generating new CA Certificate ${CA_CERT}"
	openssl req -x509 -new -nodes -key ${CA_KEY} -days ${CA_EXPIRE} -out ${CA_CERT} -subj "/CN=${CA_SUBJECT}" \|\| exit 1
	fi

Why port 587 not using self generated CA Certificate? #303

Description

Description

Failed Step

Activity

Nicepaul commented on Sep 13, 2024

bilogic commented on Sep 14, 2024

Nicepaul commented on Sep 14, 2024

bilogic commented on Sep 14, 2024

Nicepaul commented on Sep 14, 2024

bilogic commented on Sep 14, 2024

Nicepaul commented on Sep 14, 2024

cloudwindy commented on Sep 19, 2024

peixian commented on Mar 29, 2025

bilogic commented on Mar 30, 2025

M4mB14 commented on Aug 18, 2025

peixian commented on Aug 18, 2025

bilogic commented on Aug 18, 2025

peixian commented on Aug 18, 2025

bilogic commented on Aug 18, 2025

peixian commented on Aug 18, 2025

bilogic commented on Aug 18, 2025

peixian commented on Aug 18, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions