That's when you'd put EJBCA behind a reverse proxy, but how?

Prerequisites

Prepare your own root CA: You'll need the keypair as a PKCS#12 file and the root CA certificate itself as a PEM file.

Put the root CA certificate to somewhere the reverse proxy can access. /opt/root_ca.pem would be an example. Make sure it is readable by everyone: chmod 644 /opt/root_ca.pem

DNS

Make sure you've set up a (sub-)domain that points to your EJBCA server. For this blog post, I've chosen ejbca.example.com.

Procedure

We'll go over bootstrapping EJBCA itself and the reverse proxy configuration.

EJBCA

Bring up EJBCA using Keyfactor's own Docker Compose file with little modifications:

---
networks:
  access-bridge:
    driver: bridge
  application-bridge:
    driver: bridge
services:
  ejbca-database:
    container_name: ejbca-database
    image: "library/mariadb:latest"
    restart: unless-stopped
    networks:
      - application-bridge
    environment:
      - MYSQL_ROOT_PASSWORD=foo123
      - MYSQL_DATABASE=ejbca
      - MYSQL_USER=ejbca
      - MYSQL_PASSWORD=ejbca
    volumes:
      - ./datadbdir:/var/lib/mysql:rw
  ejbca:
    hostname: ejbca-node1
    container_name: ejbca
    image: keyfactor/ejbca-ce:latest
    depends_on:
      - ejbca-database
    restart: unless-stopped
    networks:
      - access-bridge
      - application-bridge
    environment:
      - DATABASE_JDBC_URL=jdbc:mariadb://ejbca-database:3306/ejbca?characterEncoding=UTF-8
      - LOG_LEVEL_APP=INFO
      - LOG_LEVEL_SERVER=INFO
      - TLS_SETUP_ENABLED=later
      - PROXY_HTTP_BIND=0.0.0.0
    ports:
      # Proxy port for the HTTP endpoint (normally 8080 when PROXY_HTTP_BIND is not set)
      - "127.0.0.1:8081:8081"
      # Proxy port for the HTTPS endpoint, it is HTTP but has
      # SSL_CLIENT_CERT header support to provide the
      # equivalent of the regular HTTPS endpoint
      # (normally 8443 when PROXY_HTTP_BIND is not set)
      - "127.0.0.1:8082:8082"

Aside from the addition of restart: unless-stopped, notice that the environment variables TLS_SETUP_ENABLED is set to later and PROXY_HTTP_BIND is set to 0.0.0.0. These two makes few changes:

• Disable generation of ManagementCA, you need to provide/generate your own CA.
• Make Wildfly (the application server) not listen on HTTPS but on two special HTTP proxy ports:
  • 8081 for regular HTTP traffic, but with proxy header support
  • 8082 for regular HTTPS traffic, but is HTTP with proxy port and SSL_CLIENT_CERT header support as a way for the reverse proxy to provide the client certificate from an mTLS handshake.

Reverse Proxy

I chose NGINX for this, but you can choose any reverse proxy you want that supports mTLS with a different CA other than the one used for the web service.

Make sure you don't have any firewall rules blocking the ports 80 and 443.

_{Since I am doing all this in Enterprise Linux, the config file structure is a bit different than the Debian packaging; so be wary.}

After install, make a copy of /etc/nginx/nginx.conf to a temporary place, you're going to use it later on: cp -a /etc/nginx/nginx.conf /tmp/nginx_prebootstrap.conf

Bootstrapping TLS with certbot

Set the server_name variable in the /etc/nginx/nginx.conf file to the (sub-)domain you've chosen.

Make sure to have the EPEL repository installed and enabled. Install certbot and its NGINX plugin (dnf install certbot python3-certbot-nginx).

Register your ACME account: certbot register --email your_email@example.com --no-eff-email --agree-tos

Obtain your TLS certificate and install it into NGINX automatically: certbot --nginx --domains ejbca.example.com --key-type rsa

Re-configuring NGINX

Copy back the config file from earlier: cp -af /tmp/nginx_prebootstrap.conf /etc/nginx/nginx.conf

Comment out the default server block that's below the line include /etc/nginx/conf.d/*.conf; in /etc/nginx/nginx.conf. It should look like this:

We're going to create two files: /etc/nginx/default.d/proxy.conf and /etc/nginx/conf.d/ejbca.conf.

/etc/nginx/default.d/proxy.conf:

proxy_set_header Host              $host;
proxy_set_header X-Real-IP         $remote_addr;
proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host  $host;
proxy_set_header Connection        "";

The following virtual server configuration is somewhat translated from what Keyfactor documentation provides with Apache2, with a slight tweak of using regular HTTP instead of using AJP.

/etc/nginx/conf.d/ejbca.conf:

server {
    listen       80;
    listen       [::]:80;
    server_name  ejbca.example.com;
    root         /usr/share/nginx/html;

    access_log /var/log/nginx/ejbca_http_access.log combined;
    error_log  /var/log/nginx/ejbca_http_error.log  warn;

    include /etc/nginx/default.d/proxy.conf;

    # CRL Distribution Point
    location = /publicweb/webdist/certdist {
        if ($arg_cmd = "crl") {
            rewrite ^(.*)$ /ejbca$1 break;
            proxy_pass http://127.0.0.1:8081;
            break;
        }
        return 301 https://$host$request_uri;
    }

    # Healthcheck and OCSP
    location /publicweb/status/ {
        rewrite ^(.*)$ /ejbca$1 break;
        proxy_pass http://127.0.0.1:8081;
    }

    location /ejbca/ {
        # Only the CRL/OCSP/healthcheck endpoints are allowed in the clear;
        # any other request redirect to HTTPS.
        if ($request_uri !~ ^/ejbca/(publicweb/webdist/certdist\?.*cmd=crl|publicweb/status/)) {
            return 301 https://$host$request_uri;
        }
        proxy_pass http://127.0.0.1:8081;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl; # managed by Certbot
    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    http2 on;
    server_name  ejbca.example.com;

    root         /usr/share/nginx/html;

    access_log /var/log/nginx/ejbca_https_access.log combined;
    error_log  /var/log/nginx/ejbca_https_error.log  warn;

    ssl_certificate /etc/letsencrypt/live/ejbca.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/ejbca.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    ssl_client_certificate    /opt/root_ca.pem;
    ssl_verify_client         optional;
    ssl_verify_depth          1;

    location /ejbca/adminweb {
        #if ($ssl_client_verify != SUCCESS) { return 403; } # uncomment after creating and installing your SuperAdmin certificate then remove the SuperAdmin public access policy.
        proxy_pass http://127.0.0.1:8082;
        include /etc/nginx/default.d/proxy.conf;
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
    }
    location /adminweb {
        #if ($ssl_client_verify != SUCCESS) { return 403; } # uncomment after creating and installing your SuperAdmin certificate then remove the SuperAdmin public access policy.
        rewrite ^(.*)$ /ejbca$1 break;
        proxy_pass http://127.0.0.1:8082;
        include /etc/nginx/default.d/proxy.conf;
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
    }


    location /ejbca/ {
        proxy_pass http://127.0.0.1:8082;
        include /etc/nginx/default.d/proxy.conf;
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
    }
    location / {
        rewrite ^(.*)$ /ejbca$1 break;
        proxy_pass http://127.0.0.1:8082;
        include /etc/nginx/default.d/proxy.conf;
        proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
    }
}

Make sure to have these files readable by NGINX: chmod 644 /etc/nginx/default.d/proxy.conf /etc/nginx/conf.d/ejbca.conf

To make sure everything went okay, reboot the entire server.

licensing

for RHEL licensing, there's two places you have to allow:

• Host: subscription.rhn.redhat.com Port: 443 Protocol: HTTPS / TLS / TCP
• Host: subscription.rhsm.redhat.com Port: 443 Protocol: HTTPS / TLS / TCP

you probably noticed that i haven't given any IPs yet, there's a reason for that; i'll explain at the end.

package updates etc.

• Host: cdn.redhat.com Port: 443 Protocol: HTTPS / TLS / TCP
• Host: *.cdn.redhat.com Port: 443 Protocol: HTTPS / TLS / TCP

why the seperate wildcard? well,

what happens when your host is in Russia, Belarus or China?

for Russia and Belarus; first off, your Red Hat account must not be in “Export Hold”; if you are, you're short of luck from the beginning.

if your Red Hat account is not on “Export Hold” state, your requests to cdn.redhat.com from RU or BY will be magically redirected to ru-by-exceptions.cdn.redhat.com, no configuration change needed.

for China however, the entire RHEL stack goes through one place: china.cdn.redhat.com; this includes licensing as well (so double check your DNF/YUM and subscription-manager configuration, see https://access.redhat.com/solutions/5090421 (login required)).

hence the wildcard.

why no ip?

other than licensing, everything Red Hat hosts use Akamai's CDN infrastructure. given that Akamai themselves don't directly provide IP lists of their CDN nodes, its somewhat hard to limit just per-IP.

for the global cdn.redhat.com endpoint, Red Hat does provide an IP list at https://access.redhat.com/articles/1525183 (no login required). JSON formatted version also available at https://access.redhat.com/sites/default/files/cdn_redhat_com_cac.json.

IPs of subdomains designated for Russia, Belarus and China are not provided, thus you always have to resort to SNI based filtering for these.

i mean if you're using a palo alto firewall and you're doing IP based filtering, what's wrong with you

so here it is, written in .reg file syntax:

Windows Registry Editor Version 5.00

;; Revert the timeBeginPeriod change done in Win10-2004 (flag is only available in Win11+)
;; https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod#remarks
;; https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ (https://archive.li/OrqYE)
;;
;; This fixes audio distortion issues that may come up on Virtual Machines (particularly old Windows versions) in VMware Workstation
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"GlobalTimerResolutionRequests"=dword:00000001

;; Disable co-installers (auto-installers) that may come with external devices
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer]
"DisableCoInstallers"=dword:00000001

;; Don't let Windows Explorer auto-determine the folder type such that it won't get hung
[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell]
"FolderType"="NotSpecified"

...but you don't know root/user password(s). what would you do?

well, this is something a friend encountered with their two oracle cloud servers.

as a prerequisite, you need to reset the root password. unless you run a hardened system image, this should be doable with changing the boot command line to initialize bash, rather than whatever initsystem the image uses. this has been documented many times.

resetting the root password

to do this; first you need to generate the remote console keys for the virtual instance from the oracle cloud console.

then, connect to the vnc console using the long command oracle gives you. (for windows, you need to install the putty suite tools because plink is required; oh and a vnc client.)

the command should open port 5900 for your vnc client to connect to the console proper.

send a ctrl-alt-del signal or issue a reset from the cloud console.

hit esc right after texts above the tianocore logo shows up. hope that the grub menu appears. if it does, you can follow the many tutorials i linked above. if it doesn't, well, you're fucked.

the hail mary approach

...not that fucked, though.

if you hit esc early, you might've entered the uefi menu instead. for which instead of resetting you enter the boot menu to enter the efi shell. hit any key other than esc to drop into the shell itself.

run type fs0:\EFI\ubuntu\grub.cfg and note the value at the end of the line starting with search.

the efi shell should give a crude editor to mess with the grub config, so run edit fs0:\EFI\ubuntu\grub.cfg and add a space withinin the value of the configfile line. yes you're intentionally breaking grub here. by breaking the configline instruction; you're making grub partially set up to use the correct /boot (or /) partition.

reboot again, you should drop to a regular grub shell this time.

you can use source (the_partition,you_noted)/boot/grub/grub.cfg to load the system environment but not execute it.

run cat (the_partition,you_noted)/boot/grub/grub.cfg and note the boot and initrd lines, if you can see them.

you can then write those two lines by hand, but changing the ro to rw init=/bin/bash in the linux line like in the tutorials and removing the rest after that ro.

then run normal. you should be in bash in a moment. do the passwd trick (like in the tutorials) and then issue a ctrl-alt-del or a reset from the cloud console.

since you broke the config in the efi partition (esp) you will be dropped back into the grub shell, this time run configfile (the_partition,you_noted)/boot/grub/grub.cfg so that the system boots.

then just login with your new password, make sure that you run update-grub to fix the issues you created previously :p

double check if its fixed by checking /boot/efi/EFI/ubuntu/grub.cfg.

exporting files when you don't have working virtual cloud network

i don't know how can this happen @ oracle cloud but i've had first-hand experience, so yeah.

we wanted to export at least a home directory so we did something very cursed.

tarball the folder, reconnect to the console using the text-serial endpoint instead of vnc while piping the output to a file, and run base64.

it did take like 1-2 hours for 2 tarballs but it worked /shrug

...but you can still visit some websites with your browser that don't do this?

you probably didn't realize this unless you ran cURL on a website and got a nice little error like this:

(sorry for the people at TUBİTAK ULAKBİM; i had to use a current example)

~ ❯ curl -v https://ulakbim.tubitak.gov.tr
*   Trying 193.140.74.21:443...
* Connected to ulakbim.tubitak.gov.tr (193.140.74.21) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /opt/local/share/curl/curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
~ ❯

but if i use msedge, the site loads just fine with TLS:

you might (understandably) think “did the root CA update and not in the trusted keystore?”, but the reality is a little bit different. the latter thought is true, but not in the way you'd expect.

most TLS certificates in the public web would have a chain like this (some exceptions apply, i won't talk about them here):

essentially, a cert will point to its issuer until it hits a self-signed one.

many systems will include only the root CAs approved by CA/Browser Forum ^{(post-publication edit, thanks @mmerkel):} the root store operator (usually the vendor) of the system.

this means that the information about intermediates don't exist unless the server gives information about it (the public keys of both the intermediate and root).

when you misconfigure your webserver to use only the host certificate for the public key/certificate, the public key/certificate of the intermediate (and root) will be missing. the only thing available will be the issuer certificate serial and its metadata.

browsers and some OSes like Android include trusted intermediates in their trusted keystore as well. this eliminates the requirement for the server to provide a full trust chain. this obviously create a false sensation of “yeah this works fine”.

but when you check the server with a TLS client like OpenSSL's s_client, the issue comes clear:

(again, sorry for the people at TUBİTAK ULAKBİM)

~ ❯ openssl s_client -connect ulakbim.tubitak.gov.tr:443 -servername ulakbim.tubitak.gov.tr
CONNECTED(00000005)
depth=0 C = TR, ST = KOCAELI, O = TUBITAK BILGEM, CN = *.tubitak.gov.tr
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = TR, ST = KOCAELI, O = TUBITAK BILGEM, CN = *.tubitak.gov.tr
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = TR, ST = KOCAELI, O = TUBITAK BILGEM, CN = *.tubitak.gov.tr
verify return:1
---
Certificate chain
 0 s:C = TR, ST = KOCAELI, O = TUBITAK BILGEM, CN = *.tubitak.gov.tr
   i:C = TR, L = Gebze - Kocaeli, O = Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK, OU = Kamu Sertifikasyon Merkezi - Kamu SM, CN = TUBITAK Kamu SM SSL Sertifika Hizmet Saglayicisi - Surum 1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jul 20 13:34:02 2023 GMT; NotAfter: Jul 20 13:34:02 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
[output snipped]

now let's look at a properly configured server:

~ ❯ openssl s_client -connect blog.linuxgemini.space:443 -servername blog.linuxgemini.space
CONNECTED(00000005)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1P5
verify return:1
depth=0 CN = linuxgemini.space
verify return:1
---
Certificate chain
 0 s:CN = linuxgemini.space
   i:C = US, O = Google Trust Services LLC, CN = GTS CA 1P5
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov 21 06:59:19 2023 GMT; NotAfter: Feb 19 06:59:18 2024 GMT
 1 s:C = US, O = Google Trust Services LLC, CN = GTS CA 1P5
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 13 00:00:42 2020 GMT; NotAfter: Sep 30 00:00:42 2027 GMT
 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
[output snipped]

you can clearly see that a trust chain is delivered by the server to the client, which the client successfully verifies with its trusted keystore, because GTS Root R1 exists in the keystore. the chain from linuxgemini.space to GTS CA 1P5 to GTS Root R1 is properly documented and delivered by the server.

(now you might ask why GlobalSign Root CA isn't sent, that's because both GlobalSign and Google Trust Services certificates are in the keystore, which makes that part of the chain redundant.)

so in the end; what i want to say is “please use fullchain.pem when you are deploying a server with TLS, you can make one if you don't have any. its just appending each pem file (cert, intermediate cert, root ca cert).”

i had the idea to write this post when i was editing pages on bgp.tools.

sorry again for the infodump, ben.

2024-08-08 edit: last year at CCC (37C3) ben made a great lightning talk about this topic, you can watch it at https://media.ccc.de/v/37c3-lightningtalks-58049-browsers-biggest-tls-mistake

Tabi takım o kadar mutlu olacak ki merch mağazalarında kullanabileceğiniz 2 gün geçerli bir indirim kodu duyuruyorlar:

This one's for you, McLaren fans! 🏆

Thank you for your support. Thank you for sticking with us. 🧡 Enjoy 60% off at the McLaren Store using the code: PODIUM60 👇

— McLaren (@McLarenF1) September 24, 2023

E haliyle biz de abanıyoruz biraz:

Ekranda “Duties”e 0 Lira yazıp 322.98 Vergi yazınca kafama takıldı, “gümrük vergisini ben mi ödeyeceğim” diye.

Hemen gönderim bilgi sayfasına bir daha bakıyorum, daha önce de okuduğum paragrafı bir daha okuyorum kendime:

Please ensure that when placing an order that the country of shipping destination is selected correctly. This is to ensure no extra charges are applied at customs.

İçim biraz rahatlıyor en azından vergiyi McLaren ödeyecek diye. Kafamda da toplam ödediğim para o günün kuruyla yaklaşık 97 Avro'ya geliyor diye de seviniyordum.

Gel gelelim bu paket 18 Ekim'de ülkeye gelsin, bir güzel de gümrüğe düşsün, SMS'i de gelsin.

DHL'i aradıktan sonra öğreniyorum ki bildirilen toplam değer 208 Pound (GBP) olduğundan (haliyle 150 Avro'yu aşıyor) standart gümrüğe tabi tutulacak. Diyorum “ya ben buna bu kadar para vermedim nasıl giriyor”, DHL de “ilk muayenede böyle çıktı, bizim yapabileceğimiz pek bir şey yok” diyorlar.

Tabi haliyle DHL bana seçeneklerimi sunuyor: 1. Paket DTP¹ olduğundan gümrük kanunu uyarınca ülkeye geldikten sonraki ilk 20 gün içinde fiziken verilmesi gereken belgeleri DHL Global Forwarding'e postalayarak çekim işlemlerini başlatmak ve beklemek. 2. Ülkeye geldikten sonraki ilk 14 gün içinde McLaren ile görüşüp paketin iade sürecini başlatmak. 3. Hiçbir şey yapmayıp paketin tasfiye edilmesine müsaade etmek.

İlk seçeneği seçiyorum, bakalım ne olacak diye. Tabi UPS ile yaşadığım kıyameti yaşamamayı umutluyorum burda.

24 Ekim'de DGF Gümrük Müşavirliği (DHL Global Forwarding'dir kendileri) bana e-posta atıyor, şu form ve belgeleri e-posta ile, paket TAREKS'e tabi olduğundan şu belgelerin aslını posta ile göndermeniz gerekiyor diye (bu sayfa sonunda yazıyor hepsi). Fakat bazı belgelerin örnekleri yok, misal TAREKS beyannamesi için gereken şablon ve dilekçe.

25 Ekim'de, ilgilenen arkadaşın telefonunu arayınca olay anlaşılıyor: bana gelen e-postanın ekleri eksikmiş.

Ekleri yolladıktan hemen sonra, gereken belgeleri çıkarıp, doldurup, imzalayıp, tarayıp, derleyip toparladıktan sonra noter yolunu tuttum.

Noterde 10 dakika (ve 569 Lira) sonrasında noter yakındaki PTT'ye gidip 62 Lira ödedikten sonra belgeleri postaladım. PTT, İstanbul'da bir tuhaf çalışıyor. 6 gün (4 iş günü) sürdü belgelerin varması. Tersi olsa, Ankara'ya net 1 günde sorunsuz getiriyorlar.

2 Kasım'da DGF'den başka bir arkadaş işlemlere başlandığını, olası gelişmelerden haberdar edeceğini iletiyor. Tabi TAREKS için 500 Lira da buradan gitti (sanırım duruma göre bu paranın iadesini isteyebiliyorum, emin değilim).

5 gün (3 iş günü) sessizlikten sonra, 7 Kasım akşamında, soruyorum bir gelişme oldu mu diye. 8'inin sabahında hemen cevap geliyor: “dün beyanatta bulunduk, öğleye kadar dosya kapanır, öğleden sonra çıkış veririz” diye. Hakikaten de paket öğleden sonra gümrükten çıktı.

Aha bugün 9 Kasım, paket geldi. Paketin bi tarafının etrafı “İncelendi” bantıyla sarılı tabi. Neyse ürünler sağlam ama. Kargo irsaliyesinde DDP, kargo etiketinde DTP yazması da ekstra ironik ;)

Buraya kadar hep kibar davranan DHL (ve DGF) görevlilerine teşekkür etmek istiyorum. E-posta ekinin eksik gelmesi sorunu dışında her şey akıcı gerçekleşti. Bu kadar frictionless bir deneyim beklemiyordum şahsen.

DHL Gümrük Portal'ına bakmadıysanız bi bakın derim: https://gumruk.dhl.com.tr

Kendi gümrük rehberleri de şurada mevcut: https://gumruk.dhl.com.tr/Content/documents/Gumruk%20Musteri%20Rehberi.pdf

DGF benden şu belgeleri E-posta ile göndermemi istedi:

• Dolaylı Temsil Yetki Belgesi (Noterden Tasdik Ettirilmez) – (Fatura üzerindeki alıcı tarafından doldurulmalı ve imzalanmalıdır),
• İthalat Gümrükleme Talimatı (Fatura üzerindeki alıcı tarafından doldurulmalı ve imzalanmalıdır),
• Yurdışına yapılan ödemenin K.kartı ekstre görünütüsü veya ödemenin banka uygulaması üzerindeki ekran görünütüsü,
• Order Details – Order İnformation görselleri
• Kimlik Fotokopisi,

Dolaylı Temsil Yetki Belgesi ve İthalat Gümrükleme Talimatı ekte olması gerekiyor.

DGF benden şu belgeleri paket TAREKS'e tabii olduğundan dolayı Posta ile ofislerine ulaştırmamı istedi:

• Gerçek Kişi Adına Kayıt Dilekçesi – İsim Soyisim imzalı
• Tareks Taahütnamesi – Noter Tasdikli ( Geçerlilik tarihi minimum 1 sene olmak üzere dilediğiniz tarihe kadar belirlenebilir. [isim gizlendi] ismi ve bilgileri sabit kalmalıdır)
• İmza Beyannemesi – Noter Tasdikli (noterden talep edilmelidir)
• Vergi Mükellefiyet yazısı – E Devlet https://dijital.gib.gov.tr/portal/mukellefiyet-borc-durum-yazilarim Dilekçelerim>Mükellefiyet/Borç Durum Yazılarım>YENİ TALEP OLUŞTUR>Mükellefiyet Yazısı Talebi>Merkez Adımlarını takip ederek belge oluşturulacaktır

1: Burada ufak bi durum var, Incoterms® 2020 ile ortalık karışmış durumda. DHL, (anladığım kadarıyla) Türkiye'de bireysel alıcılar ve/veya göndericiler için “basitleştirilmiş” DTP (Duty Taxes Paid) ve DTU (Duty Taxes Unpaid) terimlerini kullanıyor. DHL, Hollanda'da da bu formatı kullanıyor. UPS, Türkiye'de DDP (Delivery Duty Paid) ve DDU (Delivery Duty Unpaid) kullanıyor diye hatırlıyorum.↩

HSBC Bank A.Ş. - Ankara Bireysel Şubesi için kod aşağıdadır:
012300060006

Formatın ayrık hali şu şekilde:
0123 00060 006

0123 : Banka EFT kodu  (https://www.trbanka.com/banka-eft-kodlari/)
00060: Banka Şube kodu (https://www.trbanka.com/)
006  : İl Plaka kodu

Kodlar alan uzunluğundan kısa olduğunda başına 0 ekliyorsunuz:

123 --> 0123
60  --> 00060
06  --> 006 (Haliyle plaka kodlarımız XX formatında zaten.)

...After couple months, I finally did.

At first, I saw an EG25-G USB dongle from EXVIST on Amazon Turkey:

But, I remembered the entire IMEI Allowlist shenanigans after it arrived to me. So I started to play with it carefully, considering that I might return it soon.

Then I decided to look at EXVIST's own website, and found out that they sell configurable USB carrier board enclosures for Quectel mini-PCIe cards as well:

You might ask “mini-PCIe and USB? What?” and that's a valid question. Here's a fun tidbit, mini-PCIe spec actually has pins for direct USB 2.0 connection which Quectel actually markets this as an option on their product brochures.

The carrier board utilizes this and the other “reserved” pins for SIM card itself, here's a pinout from SixFab, where they also use USB D+ and D- pins (emphasis mine):

I immediately jumped onto Amazon Turkey and yep, the bare carrier enclosure is available to buy:

In the meantime, I looked at local e-commerce marketplaces other than Amazon, and I found an EC25-EUX on Trendyol:

To be extra sure, I asked the seller if the IMEIs of the stock they have are registered and they said yes:

You can guess that I immediately bought the module.

I started the return procedure of the EG25-G dongle and sent it away. I got the EC25-EUX module next day and the carrier enclosure arrived a week later.

First two cons:

• The status LED is blue. It is very bright.
• It has mounting flaps on the sides. If you want to carry this as an extension to your travel connectivity pack, you need to carefully Dremel out the flaps.

Now, let's get to how the software stuff up to speed.

I need to applaud EXVIST, because unlike Quectel themselves, they actually provide open documentation to do things:

You can grab the drivers at https://docs.exvist.com/dongle/ts/drivers.

Looking at the tools page, you will see two tools:

• Quectel's QCOM: It is a bulk configuration GUI tool which utilizes AT commands.
• Quectel's QNavigator: It is a GUI tool to manage your module (also uses AT commands). It also contains QCOM as a separate window inside the app.

Both tools will document the AT commands issued.

There will be 4 interfaces coming up when you plug the module in (gonna be using Linux paths):

• /dev/ttyUSB0: the “DM” interface, apparently its Qualcomm's QXDM.
• /dev/ttyUSB1: the NMEA/GNSS interface, which we don't use (because this is GPS, as you might have noticed).
• /dev/ttyUSB2: the direct AT interface, you can manage your modem from this.
• /dev/ttyUSB3: the AT modem interface, which Windows utilizes it as a network interface (It is the last COM port), so it is invisible. I assume Windows also does QMI from here, so you need to do the settings I mention below for proper Windows support as well.
• /dev/cdc-wdm0: this is the direct QMI. It will use the (open-source) qmi_wwan or the (proprietary) GobiNet driver.

To “”“properly”“” use your module on OpenWrt based systems (aka “using the /dev/cdc-wdm0 interface”), you need to have some prerequisites, which SixFab helpfully provides it:

• Check if the modem is configured correctly by sending the AT+QCFG="usbnet" command. It should return 0.
• If the command result shows a digit other than 0 at the end, set the option to 0 by sending the AT+QCFG="usbnet",0 command.
• Wait for 10 seconds and reboot the module by sending the AT+CFUN=1,1 command.

If your system allows a protocol named “QCI” alongside “QMI”, you can use that for your Quectel module.

I'm still messing around with this, I hope I remember to update this post with further information (Written in 2023-09-27).

2023-09-28 Update:

Looking at OpenWrt Docs, I have found out what each usbnet settings mean:

AT+QCFG="usbnet"	# check the current mode
AT+QCFG="usbnet",0	# set QMI or RMNET mode
AT+QCFG="usbnet",1	# set ECM mode
AT+QCFG="usbnet",2	# set MBIM mode
AT+QCFG="usbnet",3	# set RNDIS mode

It is weird that Quectel doesn't mention any of this in their own AT documentation. Apparently they do, its just in a separate file.

To make things extra spicy, my modem had this set to 3, which I don't know what that means. I have updated the list above.

2023-10-02 Update:

I've been trying to get the module work on macOS, but it seems like I won't be able to without modifying Apple's own support kexts.

To make sure the module actually gets loaded requires me to use AppleWWANSupport or AppleWWANSupport1 driver kexts, but they have their own vendor ID list, which needs to include Quectel's vendor ID. And they obviously don't.

2023-11-01 Update:

I've been testing the module with my GL.iNet Slate AX for more than a month at this point and with the usbnet mode set to 0 (QMI/RMNET) the modem is pretty much plug and play:

2025-01-26 Update:

“macOS support” has been lingering in my head ever since I failed to get native support working. Then recently I stumbled upon Quectel staff responding to my request last year:

So it turns out ECM is called “Ethernet Control Model” and it is basically the modem emulating an USB ethernet card with a NAT'ed network connected.

This model is natively available on both macOS and Linux. Windows requires additional drivers.

Setting it up is quite simple, run the following command through the AT interface (via a Windows or Linux device):

AT+QCFG="usbnet",1

SixFab has a support document for their SIM service at https://docs.sixfab.com/page/cellular-internet-connection-in-ecm-mode

With this figured out, I replied to the Quectel forum post:

The up-to-date plan is available on https://www.btk.gov.tr/genel-numaralandirma-plani though Some Assembly Is Required™️

The pre-assembled version is available below.

Taşıyıcı seçim kodları

Türk Telekomünikasyon A.Ş. ve STH işletmecileri taşıyıcı seçim kodları

10ZN

Kısa Numaralar

Kamu kurumlarına tahsisli kısa numaralar

1ZX

Coğrafi numaralar

Batı Anadolu illeri coğrafi alan kodları

2XXXXXXXXX

Orta Anadolu illeri coğrafi alan kodları

3XXXXXXXXX

Doğu Anadolu illeri coğrafi alan kodları

4XXXXXXXXX

Mobil numaralar

TT Mobil İletişim Hizmetleri A.Ş.’ye tahsisli alan kodları

50[15-7]XXXXXXX

SMŞH için belirlenmiş mobil numaralar

510XXXXXXX
516XXXXXXX
561XXXXXXX

Türk Telekomünikasyon A.Ş.’ye tahsisli çağrı hizmeti numaraları

512XXXXXXX

Turkcell İletişim Hizmetleri A.Ş.’ye tahsisli alan kodları

53XXXXXXXX

Vodafone Telekomünikasyon A.Ş.’ye tahsisli alan kodları

54XXXXXXXX

TT Mobil İletişim Hizmetleri A.Ş.’ye tahsisli alan kodları

55[1-59]XXXXXXX

Globalstar A.Ş. ’ye tahsisli GMPCS mobil telefon hizmeti numaraları (2110000-2120306, ve 4610000-4619999 arasındaki 20.307 numara)

592211XXXX
5922120[0-2]XX
592212030[0-6]
592461XXXX

TCDD ’ye tahsisli GSM-R numaraları (8100000-8109999 arasındaki 10.000 numara)

594810XXXX

Coğrafi Olmayan Numaralar

Ücretsiz aranır numaralar

800XXXXXXX

STH iki kademeli arama yöntemi erişim numaraları

811XXXXXXX

İSS hizmeti çevirmeli (dial-up) bağlantı erişim numaraları

822XXXXXXX

Konumdan Bağımsız Numaralar

850XXXXXXX

Katma değerli hizmet numaraları (özel içerikli ve cinsel içerikli hizmetler dışında kalan hizmetler)

888XXXXXXX

Katma değerli hizmet numaraları (özel içerikli hizmetler)

898XXXXXXX

Katma değerli hizmet numaraları (cinsel içerikli hizmetler)

900XXXXXXX

Rehberlik Hizmeti Numaraları

118ZX

(out-of-plan) Özel Servis Numaraları (444)

444XXXX

(out-of-plan) İl İçi Sabit Telefonlar

XXXXXXX

Bir arkadaşım, müşteri hizmetleriyle yaptığı kırk takla sonucunda bu sayfanın içinde olduğunu öğrendi.

Tabi fark etmek için yine detaylı okumanız gerekiyor.