tls – What is the purpose of “certificatePolicies” in a CSR? How should an OID be used?

While looking for the best way to add multiple Subject Alternative Names (SAN) to a Certificate Signing Request (CSR), this namecheap article provided the following command:

openssl req -new -addext "subjectAltName =,," 
-addext "certificatePolicies =" -newkey rsa:2048 -keyout -keyout server.key 
-nodes -out server.csr

This command makes sense, however there’s no mention of why the -addext "certificatePolicies =" options was added. Further investigation of certificate policies leads to providing a required OID, which is explained in another Security StackExchange post.

However, I’m still unclear what the purpose of this value is, and how it should be used. The server which I’m creating this CSR will require several more in the future, so to quote some text from the answer above:

The developer can choose one arbitrarily as long as it doesn’t conflict with other OIDs. Some applications/organisations apply a hierarchical structure to OID.

This implies I should use a new/different OID for each CSR I create. What is the best practice here, and how should I implement the certificatePolicies field?

tls – Should certificate pinning be implemented if the app can use many servers?

In a corporate context, mobile apps exist that require a user to enter the server address to connect to a specific instance of this vendor’s application.

The vendor sells software that it’s customers deploy on premise (or on a private cloud). The end user download the vendor’s generic mobile app from an app store and connect to their own backend.

Now I read in several sources (for example: here) that for mobile apps, certificate pinning should be implemented.

For an app that makes use of a preconfigured back end, I understand certificate pinning is relatively easy to implement and does enhance the encryption situation somewhat by mitigating the risk of fake certificates installed on the device, CA issues etc.

But for a vendor that has thousands of customers that could deploy their own instance of the software, I feel it is practically impossible to collect the certificates of their customers and to bundle in certificates or public keys (hashes). Certificate pinning is an enhancement, lacking this defensive measure is not necessarily a vulnerability.

Should the vendor in this context make the effort to implement certificate pinning with all certificate management terror that will bring? Are there any ways to pin that are feasible? Are there any alternatives to pinning that can be considered in this context?

tls – Can an SSL certificate be edited?

First of all I want to say that this question is not a duplicate.

What I want to know(And possibly get reasons) is if it’s able to edit SSL certificates.

In more depth, let’s say I have a server on my computer where when someone connects to it(and sends the HTTP request) the server get’s the Host HTTP parameter(I should clarify that the client has a poisoned hosts file) and uses it to connect to the real server, so my server retrieves the certificate of the real server, now if I edit the information of the certificate(like IP addresses) and then send this modified certificate to the client, the client should believe the certificate and thus show this green lock in the address bar.

I think this could happen if the hosts file is correctly poisoned and/or you set up a router-like device that will intercept the request to any external needed server(if any) and send false information

What do you think?

tls – why is the certificate in mbedtls unknown

I’m working on a client application that will connect to an FTPS server (vsftpd) to download files.
Now, I have ca-cert, cert and key files all setup to work with curl like:

curl -3 -k -v --ftp-ssl --tlsv1.2 --ftp-ssl-reqd --ftp-pasv --verbose 
   --cert ./en-cert.pem                     
   --cert-type PEM                                    
   --key ./en-cert.key                    
   --key-type PEM                                     
   --cacert ./ca-cert                    
   ftp://user:pass@ -O

I use the same cert, key & ca-cert with mbedtls but am unable to handshake, mbedtls_ssl_handshake() keeps returning an error (-78), this is what is done in order:

  • init cert, ca-cert, key, entropy, drbg, ssl, config

  • parse ca-cert, cert & key

  • seed RNG – mbedtls_ctr_drbg_seed with mbedtls_hardware_poll


  • mbedtls_ssl_conf_ca_chain

  • mbedtls_ssl_conf_rng with mbedtls_ctr_drbg_random

  • mbedtls_ssl_conf_dbg

  • mbedtls_ssl_conf_own_cert

  • mbedtls_ssl_setup

  • mbedtls_ssl_set_bio

  • mbedtls_ssl_handshake
    which up to the handshake all seems to go through without any issues.
    When I look at it with wireshark, I see something like:

    Response: 234 Proceed with negotiation.
    Request:looks like the certificate jumbled up
    Response 500 OOPS:
    Response :SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown

Any hints on how I best go about troubleshooting this? I have confirmed that ca-cert, cert & key are identical to the ones that are used for the above curl command.

tls – Javascript injection bettercap2 over HTTPS

I use bettercap2 http proxy and arp spoof to inject one-line js alert into http pages. It works fine, however what about https? I couldn’t find any working method to inject it without the browser’s self-signed warning.

HTTPS allows to import https source scripts only, so I tried apache2 + ngrok for green lock server with my script and it works, but I can’t understand how to dynamically add this script when users connect to sites on a LAN.

Is it possible to inject js into https sites with bettercap https proxy or maybe there is another method?

tls – Error add txt for domain:_acme-challenge when using to renew certificate

When I am using this command to auto renew my ssl certificate( version is 3.0.0):

#!/usr/bin/env bash
export Ali_Key="123456"
export Ali_Secret="123456"
/root/ --issue --dns dns_ali  
-d -d * -k ec-256 --debug

shows this error:

(Sat Jul 17 11:55:19 CST 2021) url=''
(Sat Jul 17 11:55:19 CST 2021) timeout=
(Sat Jul 17 11:55:19 CST 2021) _CURL='curl --silent --dump-header /root/  -L  -g '
(Sat Jul 17 11:55:19 CST 2021) ret='0'
(Sat Jul 17 11:55:19 CST 2021) Error add txt for
(Sat Jul 17 11:55:19 CST 2021) _on_issue_err
(Sat Jul 17 11:55:19 CST 2021) Please add '--debug' or '--log' to check more details.
(Sat Jul 17 11:55:19 CST 2021) See:
(Sat Jul 17 11:55:19 CST 2021) url=''
(Sat Jul 17 11:55:19 CST 2021) payload='{}'
(Sat Jul 17 11:55:19 CST 2021) POST
(Sat Jul 17 11:55:19 CST 2021) _post_url=''
(Sat Jul 17 11:55:19 CST 2021) _CURL='curl --silent --dump-header /root/  -L  -g '
(Sat Jul 17 11:55:20 CST 2021) _ret='0'

I could not know any error reason from the log output, why give message Error add txt for what should I do to make it work?

tls – PCI & e-banking sensitive information tokenization/encryption/obfuscation – Which fields require to be secured?

According to PCI standard all businesses that store, process or transmit payment cardholder data must be PCI Compliant.

Taking into account that we are talking about a bank, fields like card number and card holder’s name should be obfuscated when displayed on the screen.

  • What about the URL? Is it acceptable to have a request like where the card number appears as a path variable?
  • What about the case the card number appears on the request payload {cardNumber: "012345678901234"}. What about the Network Tab (F12), is it acceptable for the fields to appear raw there, while they appear obfuscated on the screen?
  • Regardless of the PCI standard, should the e-mail, tax id, physical addresses appear raw on screen? For security reasons, since this is sensitive information, they should be at least obfuscated. What about the Network Tab (F12)? Is it for the fields to appear there raw?
  • Are there any other regulations for banks, or security “tips”?

Thank you a lot in advance.

tls – Decoupled authentication flow, very vulnerable to Man in the Middle attacks?

I’m in the process of building a kinda odd mechanism to “bypass” authentication. Which of course I know its weird, but many business requirements are weird… So it is a design that derives from business decisions that state that user authentication is an impediment, also the code on the client’s backed must not be intrusive.

To explain. I have a web application and a ClientWebApp which has an SDK I’ve made that exposes an API so he can easily use it in his code and interact with that web application. The ClientWebApp is someone else’s application that wants to consume some of the information my web application can create.

The ClientWebApp is using HTTPS POST to call my web application including some user data that my web application needs in order to work. This communication happens with a client_credentials OAuth token… So far so good. The web application is storing all this information in its database and it generates a unique URL with a dynamic segment (UUID) which UUID corresponds to the key of the database entry of the incoming information from the ClientWebApp. As a last steps it returns it as a response to the POST request back to ClientWebApp.

Now the ClientWebApp is redirecting the user to that unique URL (which is actually my web application) and if the web application can find an unused UUID that matches with the UUID in the URL path it lets the user browse. Right after the match, the UUID gets invalidated so that the user is not able to refresh (or the UUID to be used again).

So my web application has no authentication (has only HTTPS) but only responds to “non-guessable” URLs that have been passed via HTTPS POST to the oauth authenticated machine.

Now I’m thinking of a scenario where a malicious person goes to a cafe or something and opens up a public wi-fi and starts sniffing the traffic, and a “dumb” end-user in the same cafe logs in automatically and starts using it as his wi-fi.

Will the malicious person be able to set a rule or something that will cut the connection when my URL comes through, intercept that URL and use it to impersonate the end-user and see their data?

I kind of feel that the answer is an absolute yes but at the same time, I’m not quite sure…

Thank you!

PS: There are many ways of tackling this otherwise but in this example I can’t create a public endpoint on ClientWebApp‘s server that I can check something with him, also authentication is out of the question when the user enters the page. Though all of that happen inside a very secure ClientWebApp (so the user has logged properly)..

tls – Determine if there’s a justified reason to block/cancel an HTTPS request (but not HTTP)

This is troubleshooting to isolate the error by testing each intermediate component.

Generally it looks like this:

Browser -> (local name resolution) -> internet -> dns
Browser -> internet -> server
Browser -> root-certs

First you need to make sure you’re always resolving the same up address.

Make sure all the devices you use have the same root certificate for verification.

Find out if you have a man in the middle intercepting your traffic. Difficult to do and that’s why they have tls and why sites should set hsts. Mitm is common and often leverages a downplay attack. That is convincing your client that the server doesn’t support higher encryption so the client falls back to insecure protocols like http.

Use a vpn like expressvpn or a digital ocean instance with openvpn installed.

Try different devices over the same network to determine if the fault is with your device or the network.

If the fault persists across networks, then it’s the server.

Is it possible to establish a secure TLS connection using only client certificate?

Is it possible to establish a secure connection using only client certificate

Speaking generally, not necessarily of TLS, the answer is “it depends”. If you consider a connection secure if it’s between two known parties, then no: with only one side authenticating (the client side), you don’t know if you’re talking to the real server or to an impostor. Same with HTTPS as it is usually deployed (without client-side certificate): the server does not know whom they are talking to, only the client knows they are talking to the right server.

If you don’t care about authenticating the server to the client, it doesn’t really matter whether TLS supports your specific setup: you can always let the client accept any certificate, which is equally secure to the server not presenting any certificate.

generate a token using A’s private key and demand B to prove that decrypt it using A’s public key

So it sounds like you do want mutual authentication.

Treating a public key as private is probably going to go wrong at some point. It reminds me of the fairy tale of Rumpelstiltskin, where nobody is allowed to know your name (public key). And in case of RSA, an attacker (having knowledge of neither the public nor private key) could submit any message to B and demand they ‘decrypt’ (message^e mod n) it using A’s public key. So an attacker does not know A’s public key, but they can ask B to encrypt anything they want to send to A using that public key. It depends on the scenario if that is actually useful for anything, but the whole scenario feels wrong.

or what’s even simpler, just demand B to send back the A’s public key

An attacker could just capture the transmission once and replay it ever after. Are you assuming there is already an encrypted channel based on the client certificate? Because then you’re not using the TLS handshake but just building something inside the TLS tunnel.

I don’t know the entire TLS specification by heart to be able to tell you that this is supported by the protocol, or all features of a popular client to be able to tell you that a specific client cannot do this, but it seems doubtful. I don’t see a need to support this: your scenario cannot really exist, since if no data can flow from B back to A, there can be no handshake. Therefore, when you exchange the key from A to B via something like SSH, B can also communicate back to A. If you want mutual authentication and there is, at some point in time, an established encrypted tunnel that was mutually authenticated, then that would be the opportunity to exchange keys. And if you’re not looking for mutual authentication but only for “a secure TLS connection using only client certificate” (i.e. only one side is authenticated), then you can use TLS as normal but ignore the validity of the server’s certificate (so like curl -k).