Category: SSL

Well, since you are here, you are probably planning to spy on traffic generated by the apps on your phone, probably looking to find out what apps are leaking your private information !

How this all works: When an application on your phone contacts a website/web-server over a secure connection, your phone checks the certificate, and checks whether or not that certificate was issued by an authority the phone trusts, what we are doing is telling the phone to add YOU to the list of trusted authorities, then, we create a proxy that the phone connects through (mitmproxy). Now, the proxy contacts the website on behalf of the application that sent the request, gets the response / contents of that page, saves a copy of that response, and repackages it using our own security certificate, then sends it to the phone, at this stage, the phone thinks the certificate belongs to the website it was contacting (Because now it trusts you), and everything works as it normally would. This does not work if the app has a pinned certificate, a pinned certificate is when an app does not trust the list of authorities the system maintains and requires a certain certificate, but this too has a workaround !

here is what you need to do.

I am assuming you already have a rooted virtual android device (AVD), if not, here are the instructions, in my case, even though it is mid 2026, i decided to go with a Google Pixel 6 with android 12 (The pixel six has updates up to the most current Android 17, but i decided to go with Android 12)

You need to create a root certificate, and install it in both mitmproxy and android, the mitmproxy gets the pem file with the certificate and private key (So that it can create certificates for websites on the fly), while android gets the one with the certificate (Obviously)

1- Gnerate the private key

openssl genrsa -out android-mitm-ca.key 4096

2 – Create the CA certificate

openssl req -x509 -new -sha256 -key android-mitm-ca.key -out android-mitm-ca.crt -days 3650 -subj "/C=JO/O=Android Traffic Analysis/CN=Android MITM Analysis CA" -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign"

3- Installing mitmproxy (On your debian machine)

install Prerequisites:

sudo apt install python3-dev libffi-dev libssl-dev libxml2-dev libxslt1-dev libjpeg-dev zlib1g-dev

Debian 13 does not have it in repositories (12, and 14 do !), so we need to install from binaries downloaded from the website ! so i put them in /opt/mitmproxy and symlinked the files in /usr/local/bin

4- Concatinate/combine key and cert into 1 file for the mitmproxy

cat android-mitm-ca.key android-mitm-ca.crt > ~/.mitmproxy/mitmproxy-ca-my.pem
chmod 600 ~/.mitmproxy/mitmproxy-ca-my.pem

5- running and check that mitmproxy is using our cert

First, run mitmproxy.

NO-GO: mitmproxy –listen-host 192.168.7.119 –listen-port 8080 –certs “*=$HOME/.mitmproxy/mitmproxy-ca-my.pem” (No go because certs is for individual domains)

NO-GO:

mitmproxy --certs "*=$HOME/.mitmproxy/mitmproxy-ca-my.pem"

Or if needed

mitmproxy --listen-host 192.168.7.119 --listen-port 8080 --set confdir="$HOME/.mitmproxy-my"

Or if you want access from outside your network

mitmproxy --listen-host 192.168.7.129 --listen-port 8080 --set block_global=false --set confdir="$HOME/.mitmproxy-my"

From another terminal, let us try to get the contents of example.com through the proxy:

openssl s_client -proxy 192.168.7.119:8080 -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject

Now, if the proxy works as intended, and is correctly signing our requests with our own certificate, we should see something like isuer: Android MITM Analysis CA (The name we chose)

So, now our proxy is ready and serving, all that remains is relevant to Android, we have already made the android certificate to add (OUR_HASH.0)

Installing the certificate on the android phone

The only thing that is confusing about this section is that not all android phones work in the same way ! I am deliberately using Android 12 (Will install most software while being somewhat easier to tinker with), you on the other hand may be using android 16 or 17 (The latest at the time of writing).

Also, I am using a virtual android phone (With Android Studio), you may be using an actual rooter physical phone !

So, I will outline when something is going to be different on other android versions, and you will have to figure it out (Use Google, or gemini or something)

6- Certificate File Name for android

figure out the hash for the filename of the Android file (The file name should be “hash.0”, replace hash with the actual hash resulting from the below) this is how android expects the file name to be

HASH=$(openssl x509 -inform PEM -subject_hash_old -in android-mitm-ca.crt | head -1)
echo "$HASH"

Now, copy the file android-mitm-ca.crt and name the copy the same as the resulting hash with an added .0 at the end (THEHASH.0)

7- If android 16+ (I am using 12, but if you have 16+)

If your rootAVD image is Android 16 or above, don’t blindly follow the old /system/etc/security/cacerts/ procedure. Android 16 changed the system certificate location, and current mitmproxy documentation has a separate procedure involving a Magisk certificate-moving module.

check your android version

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.sdk
adb shell getprop ro.product.cpu.abi
adb shell su -c 'id'
$ adb shell getprop ro.build.version.release
12
$ adb shell getprop ro.build.version.sdk
31
$ adb shell getprop ro.product.cpu.abi
x86_64
$ adb shell su -c ‘id’
uid=0(root) gid=0(root) groups=0(root) context=u:r:magisk:s0

So, in my case, I am running android 12 ! Software development kit 31 (API level), X86 cpu, and (context=u:r:magisk:s0)

8- Explore the filesystem

Let us check and explore the files and folders on filesystem

> adb shell su -c 'ls -ld /system/etc/security/cacerts'
drwxr-xr-x 2 root root 4096 2023-07-26 23:02 /system/etc/security/cacerts

> adb shell su -c 'mount | grep -E " /system | / "'
/dev/block/dm-4 on / type ext4 (ro,seclabel,relatime)

> adb shell su -c 'ls -l /system/etc/security/cacerts | head'
total 952
-rw-r--r-- 1 root root 2871 2023-07-26 23:02 01419da9.0
-rw-r--r-- 1 root root 2914 2023-07-26 23:02 04f60c28.0
-rw-r--r-- 1 root root 2345 2023-07-26 23:02 0d69c7e1.0
-rw-r--r-- 1 root root 4622 2023-07-26 23:02 10531352.0
-rw-r--r-- 1 root root 4724 2023-07-26 23:02 111e6273.0
-rw-r--r-- 1 root root 4308 2023-07-26 23:02 12d55845.0
-rw-r--r-- 1 root root 2599 2023-07-26 23:02 1ae85e5e.0
-rw-r--r-- 1 root root 4931 2023-07-26 23:02 1df5a75f.0
-rw-r--r-- 1 root root 4535 2023-07-26 23:02 1e1eab7c.0

So, we do have the path /system/etc/security/cacerts on the phone, system (See second command above) is mounted read only, there are 952 certificate files in the /system/etc/security/cacerts folder.

Reminder: On Android 12, the traditional system CA location we’re interested in is: /system/etc/security/cacerts/ , The certificates are stored there using the OpenSSL subject-hash filename convention, e.g.: xxxxxxxx.0

The plan at this stage is to use magisk to add our certificate as an overlay, this way, we don’t need to modify the actual system, meaning, we will not be mounting system in read-write mode, read-only is fine by us

9- Explore Magisk

So let us start by checking what version of MAGISK is installed on the phone, and where it lives

> adb shell su -c 'magisk -v'
26.4:MAGISK:R
> adb shell su -c 'magisk --path'
/debug_ramdisk
> adb shell su -c 'ls -la /data/adb/modules'
total 24
drwxr-xr-x 3 root root 4096 2026-08-26 12:05 .
drwx------ 6 root root 4096 2026-08-26 12:11 ..
drwxr-xr-x 3 root root 4096 2026-08-26 12:07 hosts

Since this is rootAVD/Magisk, the clean approach is to use a Magisk overlay so we don’t modify the underlying system image.

10- Create the Magisk module with the certificate in it !

we can create our own small Magisk module specifically for the CA without touching the original system image. (the only existing module is hosts)

To create a magisk module we need to do the following

10.1- Create an identical folder structure on my debian machine *(Yours can be windows)

mkdir -p ~/.mitmproxy/module/system/etc/security/cacerts

Move your certificate (xxxxx.0) to the cacerts folder we created above

Now create the module file (Module dfinition file), obviously you can create it with a text editor as well if you wish.

cat > ~/.mitmproxy/module/module.prop <<'EOF'
id=android-mitm-ca
name=Android MITM Analysis CA
version=1.0
versionCode=1
author=Voodoo
description=Custom CA certificate for controlled Android traffic analysis
EOF

Now, put the contents of the module directory (Without the module directory itself) in a zip file

cd ~/.mitmproxy/module
zip -r ../android-mitm-ca.zip .

Now, open the zip file in fileroller (or 7-zip or winrar, whatever suits you) and make sure we have

module.prop
system/
system/etc/
system/etc/security/
system/etc/security/cacerts/
system/etc/security/cacerts/XXXXXXXX.0

If all looks good, super, we have the zip file for android…. go ahead and push it to the android virtual machine

> adb push ~/.mitmproxy/android-mitm-ca.zip /data/local/tmp/

Now, when the above works, install the zip file with magisk

> adb shell su -c 'magisk --install-module /data/local/tmp/android-mitm-ca.zip'
- Device is system-as-root
**************************
 Android MITM Analysis CA 
 by Voodoo 
**************************
*******************
 Powered by Magisk 
*******************
- Extracting module files
- Done

If you get an error above DO NOT REBOOT, only reboot if you get a message like the one i got. if not, Sorry man, you need to reverse the steps above ! something with the rootAVD restore command should do

Now, after rebooting (adb shell reboot), run this to see if our certificate appears !

adb shell su -c 'ls -l /system/etc/security/cacerts/'

Looks fine to me, but let us double check (replace the xxx with your actual file name)

adb shell su -c “ls -l /system/etc/security/cacerts/xxxxxx.0”
-rw-r–r– 1 root root 2000 2026-08-27 20:28 /system/etc/security/cacerts/xxxx.0

And if everything was done correctly, “adb shell su -c ‘mount | grep ” / “‘” should still show read-only

Now, let us play, I am very skeptical that this would work (Unless your android has openssl), but it can’t hurt to try… anyway, failiure here means nothing is the error is that “openssl: inaccessible or not found”, it is expected, and means nothing

adb shell su -c "openssl x509 -in /system/etc/security/cacerts/fea8a918.0 -noout -subject -issuer"

Pinned certificates

there are ways to get around this, ways from things as simple as using apk-mitm to remove the pinning, all the way to more serious stuff such as using jadx to modify the software before playing this game.

Here are some tools that can come in handy for this

• FRIDA: Lets you inject snippets of JavaScript or your own library into native apps + simple tools built on top of the Frida API.
• APK-MITM: (https://github.com/shroudedcode/apk-mitm): Remove certificate pinning from APK files
• objection is a runtime mobile exploration toolkit powered by Frida, which supports certificate pinning bypasses on iOS and Android.
• ssl-kill-switch2 blackbox tool to disable certificate pinning within iOS and macOS applications.
• android-unpinner : From the same people who make the MITMPROXY, it modifies Android APKs to inject Frida and HTTP Toolkit’s unpinning scripts.

apk-mitm

node --version
npm --version
sudo apt install zip unzip
npm install -g apk-mitm

Now, to remove the pinning in your app

apk-mitm <path-to-apk>

First of all, check what ports nginx is currently listening on, you can do that with any of the following commands

netstat -tlpn| grep nginx
ss -tlpn| grep nginx

So, you probably found nginx listening to port 443 for SSL connections, and on port 80 for plain http….

On many occasions, you may want other application (Such as varnish or apache) to be listening on port 80, So nginx needs to move to another port, in this example, I am moving it to port 8080

Step 1: Go to sites available, there is the default site, and there are any other sites you added to nginX, open those config files that you will find in /etc/nginx/sites-available, search for 80, and replace it wherever it may occure with 8080 or any port of your choice, restrictions are the following, port numbers under 1024 will requier root privilages (So keep it above 1024), and the maximum port number is 65535, Also port 0 can not be used for http (Relevant to UDP though)

Let’s encrypt is a Certificate Authority (CA) run by Internet Security Research Group (ISRG), and is sponsored by some of the biggest name in the web industry

You are probably here to create a certificate, not get a history lesson ! so Let me cut the chase, for those who want to know more, there is always wikipedia (Let’s encrypt on Wikipedia)

So let’s encrypt provides certificates for domain names, including wildcard certificates (Which I will get to by the end of this article), What we are going through here is the manual process, which serves to give you a taste of how things work, in practice, you are encouraged to use on of the automated methods for multiple reasons, one compelling such reason is that Let’s encrypt issues certificates valid for three months only ! You don’t want to have to cater to your certificate every three months do you ?

To simplify things, I will create a step by step video to demonstrate the creation process ! and post it here, but for now, I will simply take you through the steps, in this tutorial, all you need is SSH access to any server including one you have at home ! or even maybe a virtual machine running Linux inside your windows computer, anything goes, once you have a certificate, you can move it to your production server, this allows me to keep this as general as possible, and this is done using the –manual option, So without further ado, let me get to it

1- login to a linux server and install certbot, the tool that allows you to get certificates from let’s encrypt, On the official website, they promote the use of SNAP, here, I will skip snap and use Debian’s repository ! simpler and there is no need to get into snap

apt install certbot

Now that you have certbot, let us create a certificate for the domain example.com (replace it with your own)

certbot certonly --manual --preferred-challenges http

The –preferred-challenges directive allows you to specify what challenge (http or dns) you would like to perform, the manual plugin is basically the same as webroot plugin but not automated, which is a hassle to keep up to date as this form of issuance needs to be renewed manually every 3 months, (You can take extra steps to automate this) which i will describe later on another post to keep things tidy

Now, as soon as you enter the above, you will enter an interactive dialogue with the following steps

Note: If you want to create a wildcard certificate for your domain name, let’s encrypt allows the use of the * wildcard, but only supports DNS challenge, so the command must reflect that, So when asked for a domain, simply enter *.example.com (or -d ‘*.example.com’), should work normally

As soon as you are in, you will be asked

1- An email for notifications
2- Do you agree to the terms of service ?
3- Would you like to subscribe to the newsletter ?
4- enter your domain names (you should enter both example.com and www.example.com separated by either a comma or a space)
5-

Create a file containing just this data:

Pg1xJ.........-88

And make it available on your web server at this URL:

http://example.com/.well-known/acme-challenge/Pg1...........xuu_0

6- Now you need to create the 2 challenge files, one for exmaple.com and the other for WWW.example.com

Create a file containing just this data:

Ud4m81x..............zupbWEz-88

And make it available on your web server at this URL:

http://www.example.com/.well-known/acme-challenge/Ud4........550

(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet.)

--------------------------


IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your certificate will expire on 2023-03-11. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

At this stage, there are things you should remain aware of

1- DO NOT RENAME OR MOVE THE CERTIFICATES, they need to be in place for renewal if you decide to not automate and check on your certificates every 3 months.

2- Copy (Don’t move) them to the ssl directory, and add them to your config files, the only files you will need to include in your nginx or apache2 config are as follows

For apache 2, you need to use the following 2 lines, modify the path to the files to wherever you have placed them

      SSLCertificateFile /etc/apache2/ssl/example.com/fullchain.pem
      SSLCertificateKeyFile /etc/apache2/ssl/example.com/privkey.key

And for nginx

        ssl_certificate /etc/nginx/ssl/allspots.com/fullchain.pem;
        ssl_certificate_key /etc/nginx/ssl/allspots.com/privkey.pem;

So, restart apache or nginx, and you should be able to see the certificate in action, so this is the simplest way to use let’s encrypt, in my next post, I will

Now, after 3 months, the simplest way to renew the certificate is to issue the command

certbot certonly --force-renew -d example.com www.example.com

This tutorial is done on a debian 11 system… it should work for wildcard (For all subdomains under a domain), but also for subdomains or the primary domain, obviously, all you need to do is replace the * which denotes wildcard with the subdomain of your choice, so *.qworqs.com is wildcard, yazeed.qworqs.com is a subdomain 😉 so let us get started

Let’s encrypt has certainly revolutionized the world of SSL certificates (By making them free), but when it comes to wildcard certificates, let’s encrypt will require more than just generating the certificate, it will require a system that automatically alters DNS at your registrar, and differs from registrar to registrar.

So while I am developing, and need a wildcard SSL, I can simply generate a self signed wildcard security certificate, and teach my browser to accept it, and that is that, so here is how to generate that certificate !

So let us get started, first let us create a public and private key in one go, and a folder to store them !

cd /etc/ssl
sudo mkdir qworqs.com
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/qworqs.com/wildcard-ss.key -out /etc/ssl/qworqs.com/wildcard-ss.crt

I will personally skip selecting a strong Diffie-Hellman group… this file though goes somewhere else in the nginx directory, and can be generated like the following, but again, I don’t need it atm.

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

Now you are done with creating everything you need, the next step is to install them into your nginx configuration

So all you need is to add the following 2 lines into your server section within the website config file 😉

    ssl_certificate /etc/ssl/qworqs.com/wildcard-ss.crt;
    ssl_certificate_key /etc/ssl/qworqs.com/wildcard-ss.key;

Now all you need is to restart nginx, and you should get a warning in your browser, I accept the warning, then make it permanent in firefox from the settings

Settings -> Privacy & Security -> Security -> Certificates -> View Certificates... -> Servers Then switch it from temporary to permanent

And that’s that

This post is very outdated, you might want to check a more recent version of it at (Self signed wildcard security certificate for apache or nginx), even though it says WILDCARD in the title, it clearly shows how to make one that is not a wildcard certificate

It may be true that tutorials teaching you how to create and install a self signed security certificvate are everywhere, this one here i put for my own purposes, because i use this one that i wrote as copy and paste instructions for speed. I added things to explain why we are doing everything

Here we will discuss installing a self signed certificate (Acting as your own certificate authorite) …

If you are not sure if what you need is a self signed certificate or a proper secure certificate signed by a certificate authority, you can see the difference here

In this tutorial, we will install a self signed certificate on a debian squeeze machine. Please keep in mind that 1 certificate can be installed per IP address. If you need to install more certificates for more hosts, please have a look here.

We are sssuming you have apache installed, other web servers have different installation instructions, but the generation procedure remains the same

The steps we will take are

A- get the system ready
B- Create a private key
C- Create a certificate signing request from the private key
D- Create a certificate from the certificate signinig request
E- Install the certificate and the private key
F- Decrypt the private key (Optional)

A- get the system ready

1- Install openssl

On my debian system, this is done with the following command, on other systems, the installer may be different

apt-get install openssl ssl-cert

2- Create a directory we can work in

mkdir /etc/apache2/ssl

B- Create a private key

Creating a private key is as simple as

1- Go to our working directory

cd /etc/apache2/ssl

2- To create a private key, Issue the command

openssl genrsa -des3 -out myprivate.key 4096

A password of your choice is requiered (You must enter it twice).

You will then have a private key in the file myprivate.key

This is the encryption key for your private key, and even though this is an encrypted private key file, this key should never be shared with anyone. Since if you do decrypt it in the optional step below, and if it is ever shared with anyone after it is decrypted, they can create a certificate just like the one we are creating and fool a visitor into thinking they are on the correct website (in case of a man in the middle attack for example).

C- Create a certificate signing request from the private key

The certificate signing request is the file we normally give to a certificate authority so that they can create a certificate for us, but in this case, we are the certificate authority (Self signed certificate), we will therefore create a Certificate Signing request and sign it ourselves

1- To create a file containing the Certificate signing request data, all we need to do is issue the following command

openssl req -new -key myprivate.key -out signingrequest.csr

You will now be asked for (Keep your eyes open for the common name since it is the most important)

* Your Pass Phrase, the one you chose for the private key (To create a request from a private key, we need the decrypt and read the private key)
* Country Code (US), State…, CITY, Organisation Name, Organisation Unit
* Common name, and this is the most important, this is either your domain or sub domain, if it is your domain, do not add WWW and enter example.com if it is a sub domain enter subd.example.com
* A Challenge password of your choice

* Enter anything into the optional company name.

We will now have 2 files in the directory, our private key (myprivate.key) and a certificate signing request (signingrequest.csr), we have 2 passwords, the private key’s encryption password and the signing request’s challenge password

D- Create a certificate from the certificate signinig request

openssl x509 -req -days 3650 -in signingrequest.csr -signkey myprivate.key -out mypublic.crt

Now, you will be asked the the Private Key’s pass phrase, the first password, Again to decrypt the private key so we can create a certificate.

We will now have 3 files in the directory, our private key (myprivate.key) and a certificate signing request (signingrequest.csr), and out certificate file (mypublic.crt)

E- Install the certificate and the private key

At this point, we have a public key (mypublic.crt), and a private key (myprivate.key), we can now install those on apache, and start using our certificate.

To install certificate on apache, we must

1- Enable mod ssl on apache, this is done with the command

a2enmod ssl

2- Make sure Apache is listening on the SSL port (443 by default)

On a debian system, you will need to verify the file ….

3- Fix the host’s config file to use the certificates

How this is done depends on how your system defines websites in apache, The easiest way to do this on a debian system is to copy the file mysite from the /etc/apache2/sites_available folder into a file called mysite_ssl (The mysite file could be called anything like polosite.com.cfg), then open the new file for editing, change the Virtual Host Line at the top to <VirtualHost *:443> (You may also change the 8 with your IP address) then scroll down to the end of the new file, and right before the end of the Virtual Host, add the following lines

<VirtualHost *:443>
...................
...................
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/mypublic.crt
SSLCertificateKeyFile /etc/apache2/ssl/myprivate.key
</VirtualHost>

4- Restart apache server

On a debian system, the apache server is restarted with the command

/etc/init.d/apache2 restart

IMPORTANT: Now, when you restart the apache server, you will be asked for the password you chose when you created your private key, the next step below will make apache not ask for a password, but will also create a risk if your unencrypted key should fall into a malicious user’s hands. Worth mentioning that most websites do decrypt the private key, then make sure it is in a directory only root user can access, again, by default your private key is encrypted, decrypting it means you need to take very good care of it.

F- Decrypt the private key (Optional)

openssl rsa -in myprivate.key -out myprivate.key.insecure
mv myprivate.key myprivate.key.secure
mv myprivate.key.insecure myprivate.key
  

Now, restarting Apache should not ask you for a password

G- Working with browsers

Firefox will allow you to add this certificate to it’s memory, whenever this certificate is presented for this hostname, Your modified Firefox will consider it a valid certificate

Four days of godaddy SSL hell (starfield technologies certificate)

So, i am not writing this to mock godaddy or godaddy resellers or support, this is just a problem that you need to understand before you call godaddy (or any of their resellers) simply to save time and not to have to wait for 4 days like i did

When i submit my security signing request (csr file) to godaddy or wild west domains, the error i get reads

Common name example.com is already present in a current certificate.

The reason to this is that someone (probably you or a previous owner) already issued a certificate for that domain from another account.

SOLUTION: Certificate, or even expired certificate must be REVOKED, cancelled is not good enough, the magic word is REVOKED, when the certificate expires, you can not revoke it, you must contact support and tell them that you need to revoke it by email.

So, i have not taken the time to organize the text below this line yet, if you are arguing about something in an effort to reduce your wait time, see below for whatever you need, but again, i did not refine any text below this line or organized it or even checked that it is correct.

———————————————————————-

UPDATE: Godaddy wrong again, when i get the time i will listen to the recorded conversation (because my phone auto records all conversations) and tell you exactly what you need to do to not rely on the faulty godaddy manuals, in short this is what happened (as i remember it is close to this)

So, here is what my conversations with godaddy comes down to, not accurately, but in short, what it comes down to (for my reference, the file is godaddy ssl Voice-0003.amr)

But as i start to get skeptical about this resolving itself in a few hours, i will call jet (the very helpful customer care representative) again and see if anything can be done.

Godaddy (Jet): After canceling the certificate, you need to wait for three days
Me: No, i am sure we have to revoke it, and since it is expired, i can not revoke it
Godaddy (Jet): No you are mistaken, after cancelling, we wait for three days then put in a new request
Me: Ok i will wait
I wait for 2 days, then call again as my website is down
Me: are you sure that within 3 days the system will do cleanup, if the job runs once every three days, 2 days increases the odds of what i was saying being right, can you please double check ? my website has been down for two days
Godaddy: no need to check, there is nothing we can do
And after 3 days of still no luck, i call again
Me: hi, i have waited for 3 days
Godaddy (denis): yes sir, for a certificate to get cleared from the system it needs to be revoked, i will have them send you an email so we can revoke it by email.
me: Seriously, that’s what i said 3 days ago
Godaddy (denis): I wonder why they did not do that on the first day
Me: thanx anyways