Two factor authentication

coffeecup25

@coffeecup25 I simply don't get what you are talking about. You take those files from the standard archive and rename them. Fine.
So now they aren't named like <firewallname>-<proto>-<port>-<user>.any but are called fred.p12, fred.key and fred.ovpn. Fine again.
Your real VPN user name is - just for example purposes -> fr3d981.

So you say nothing in those files point to that name? That isn't the case with strict user CN matching active. With that option, your VPN user fr3d981 must have a matching cert with correct common name belonging to said name. So as @Derelict tries telling you, the .p12 file has this name in its CN Tag encoded. Thats nothing you can simply rename as the certificate itself is created with it.

We use that for remote access type of OpenVPN Servers all the time and regardless of using it in windows only or on Android, Linux, Mac or whatever, you can check on the correct username via certificate on all these systems because the CN simply HAS to match, otherwise it would not fulfill that option. And if you don't use strict user CN matching, you could use any cert valid from the same CA as a login factor, that's not what many of us wants. Just out of curiosity I checked a few of those "standard archive" packages and any .p12 file has its CN= value correctly set to the username it needs for logging in. Anything else would be very strange indeed.

And NO, this is not "encrypted" anywhere in the certificate but plain text readable as those certificated created via pfSense and the webGUI don't have a password set on them. You just hit enter.

Example:
Enter Import Password: (just hit enter)

MAC verified OK
Bag Attributes
    localKeyID: 4D 73 A3 1B A8 30 CC E1 E4 70 8E 21 90 2A 4F C6 37 91 7C 89
subject=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=jegr/OU=VPN
issuer=/C=DE/ST=xx/L=xx/O=xx/emailAddress=hostmaster@xx/CN=Company - VPN/OU=VPN
I x'ed the other values as they aren't important but the CN from the subject line. Regardless how you name the file, the CN is always there. Sorry, but I don't see how your renaming would add any security if you can check the username with a simple call to "openssl pkcs12 -in <certname>" - seems more like obscurity without security gain. No offense.

Greets</certname></user></port></proto></firewallname>

If it's encoded then it's encrypted because nothing is readable in that file. NOTHING. Yet OpenVPN works fine and it won't connect unless the username matches the CN on the certificate. I used to work in IT and it frustrated me to no end when people argued about gravity even when proof of gravity was right in front of their nose. Generally they were thinking of things that had nothing to do with the example at hand yet resisted change and used arguing with gravity to fight change. IT people are by far the most resistant to new idea people I have ever met in my long life. If you can't fight gravity, then look for 'inconsistencies' or destroy reputations if all else fails. Ah … the good old days.

The excerpt in your post did not come from the p12 file I referenced. The reason I know is that some of it is humanly readable. Nothing in my p12 file is. So you must be looking in the wrong place ... the place that does work as you described ... not the place that works as I describe.

OpenVPN apparently supports several client config file formats. Your favorite will not support my objective. Mine does.

Or - just spitballing here - perhaps the CN field you see is not the CN the client program references to validate matching. Maybe the server does that using another method that matches the username to the certificate in use and, on the server, to the certificate the username should be using? Therefore, it's use is for something other than matching and an alternate OpenVPN client format does not necessarily require it. Just a guess.

Actually try it and you will see what I mean. Really. Gravity exists. I use it frequently.

You try to help someone out and get ganged up on by people who shriek ... "I don't do it that way and I never heard of it so it can't work and you are wrong. I will argue with you about it and ignore everything you say until you agree I am smarter than you." Why do I bother?

Derelict

It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:

coffeecup25

@Derelict:

It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t

I just used notepad++ find - not there. Deal with it.

kpa

@coffeecup25:

@Derelict:
It's encoded with pkcs12 but it is NOT encrypted, bro. It's there for anyone to see.

SEE ALSO: pkcs12(1)

This is not "encrypted" either:
-----BEGIN CERTIFICATE-----
MIIEwzCCA6ugAwIBAgIBCDANBgkqhkiG9w0BAQsFADCBiDELMAkGA1UEBhMCVVMx
DzANBgNVBAgTBk5ldmFkYTESMBAGA1UEBxMJTGFzIFZlZ2FzMRUwEwYDVQQKEwxU
ZXN0IE9wZW5WUE4xIzAhBgkqhkiG9w0BCQEWFGRlcmVsaWN0QGV4YW1wbGUuY29t
I just used notepad++ find - not there. Deal with it.

Of course you won't find it like that. Derelict is just trying to give a subtle hint that there is something that you haven't grasped yet. The file is ASCII-armored using a base64 encoding that protects the file from being mangled when it passes trough a transfer channel that is not 8-bit clean. If you open the ASCII-armored file with proper tools (the openssl command line tool for example) the encoding is removed and all of the details of the certificate are open for everyone to see in plain text including the CN field.

johnpoz

"If it's encoded then it's encrypted because nothing is readable in that file"

Wow.. Talk about not understanding the basics…

Its encoded, not encrypted.. You really need to look up the difference..

Lets try and use an example you might understand. You speak english, if I tell you something in Latin or French or German.. Your not going to understand what it says. But someone that speaks latin or french or german would. You can translate it to english without having to "decrypt" anything.. You just have to understand the language its encoded with.

If its encypted.. Say with a keyed ceaser as simple example. It might be english but you can not understand it without "decryption" and know what the key or how to decrypt it even if you speak english.

You may not read or speak "ASCII-armored using a base64 encoding" but the programs do and simple as translating them into english for you. Its like taking the french sentence and pasting it into google translate.

But if I encrypt the english, french, latin you can paste it into google translate and all you will get back is gibberish..

Something that is encrypted can not be translated by anyone that knows how to use google.. Encryption requires you have/know what the key to the cipher to be able to translate it..

Here is online version of decoder for a pem file
https://www.sslshopper.com/certificate-decoder.html

Take your cert and paste in its info from certs you think are so "encrypted"

coffeecup25

@johnpoz:

"If it's encoded then it's encrypted because nothing is readable in that file"

Wow.. Talk about not understanding the basics…

Its encoded, not encrypted.. You really need to look up the difference..

Lets try and use an example you might understand. You speak english, if I tell you something in Latin or French or German.. Your not going to understand what it says. But someone that speaks latin or french or german would. You can translate it to english without having to "decrypt" anything.. You just have to understand the language its encoded with.

If its encypted.. Say with a keyed ceaser as simple example. It might be english but you can not understand it without "decryption" and know what the key or how to decrypt it even if you speak english.

You may not read or speak "ASCII-armored using a base64 encoding" but the programs do and simple as translating them into english for you. Its like taking the french sentence and pasting it into google translate.

But if I encrypt the english, french, latin you can paste it into google translate and all you will get back is gibberish..

Something that is encrypted can not be translated by anyone that knows how to use google.. Encryption requires you have/know what the key to the cipher to be able to translate it..

Here is online version of decoder for a pem file
https://www.sslshopper.com/certificate-decoder.html

Take your cert and paste in its info from certs you think are so "encrypted"

Looks like we're playing a game of telephone now and the original objective has been lost to technobabble.

The objective was to download the standard three file archive folder, zipped. Then rename the files and modify the ovpn file to reflect the new file names. This obfuscates the actual username which adds more security to the client assuming the server is matching client names to common names associated with the certificate.

From there we went to … "no no you can't do it cause I never heard of that before". Well, I do it and the cn is not in any of the files I unzipped and put into the config folder. Look for yourself. If it's encoded but not encrypted who cares. It's still unreadable unless you apply some weird forensics to it. Nobody will do that except possibly the FBI or a bored ET like hacker who lives in a basement and hasn't a life otherwise. And they need possession of the laptop to do it and want to do it, as opposed to just selling it for a few bucks on ebay after they stole it. Even so, no CN to see if they steal my windows laptops. Sorry about yours, you should do it my way. Even if ET does steal my laptop, it takes 2 seconds to delete the certificates. ET is locked out.

Your reply, in this context, makes no sense at all.

I've looked. It's not there. Lots of user IDs and even after a full server rebuild after I decided to start from scratch on everything again. Still zip with the CN in any file downloaded using the standard archive. As I said, I don't know or care about any of the other file formats that can be downloaded using the client export package because I'm only interest in what works. If it's encoded and not encrypted, who cares? It's still unreadable.

Even assuming ET gets my laptop and happens to have a translator with him that can decode the file that hides my username ... assuming it takes that much work and there's that kind of coincidence - I'm still pretty well protected using my system as the alternative is full disclosure if another type of file is downloaded using the client export package. Then anyone can see it in that case. Most people won't know anything about ET's skill set. I know, ET is lurking in your bedroom closet just waiting to grab your openvpn device.

Why so much hostility for a little good advice. Dilbert describes brittle IT people brilliantly.

johnpoz

"It's still unreadable. "

It is still readable.. And the common name on the cert is still .2 seconds to pull out of the encoded cert.. If you want to use a different user name for the account the user has to know that is different than the common name on the cert that is one thing. But don't think your creating any extra security by just renaming the cert from johnpoz to john. The CN of johnpoz is still in the cert and easy to view.

If your server is set up (box checked) for common name to match certificate

For example, pfSense names the file and the certs with the user id. Rename them and edit config with the new names. It's a little tedious but nobody knows your name if you do it.

Your talking about the attached check box right - see attached.

The point trying to get across to you is even if you rename the cert or config file so it doesn't have the user name on it - its still in the CERT file, while sure grandma can not read it.. But anyone else could with the simple url I posted..

So here is test cert I created.

I can call/rename this cert anything I want.. So sure pfsense calls it say

pfsense-TCP-443-billy.p12

that p12 has the cert in it, can be de-encoded and show you the CN or username that has to match. Your just causing yourself extra work if you think this is adding security from anyone other than say your grandma.

Not sure where you think there is hostility.. I am just trying to explain that encoding is not encrypted.. And your not actually hiding that CN from anyone by renaming the cert or config file or whatever it is your taking the time to rename so it doesn't match the CN.. Since the CN is there for anyone to view that has access to the file.. Be it they ETs skill or not.. If they know anything about how openvpn works….

So if your going to do a check that the username has to match the CN then not having the CN/Username pop up in the openvpn gui makes no difference. What making sure the the username matches CN for is that Billy doesn't access the vpn with Susan's username and password.. If they have billy's cert then they have to know billys password along with having the cert.

The 2FA comes from having to have the cert and knowing the password. Knowing the username does not remove the 2nd Factor.. There is still something you have and something you know.

enforcematch.png_thumb

billycertcn.png_thumb

coffeecup25

@johnpoz:

"It's still unreadable. "

It is still readable.. And the common name on the cert is still .2 seconds to pull out of the encoded cert.. If you want to use a different user name for the account the user has to know that is different than the common name on the cert that is one thing. But don't think your creating any extra security by just renaming the cert from johnpoz to john. The CN of johnpoz is still in the cert and easy to view.

If your server is set up (box checked) for common name to match certificate

For example, pfSense names the file and the certs with the user id. Rename them and edit config with the new names. It's a little tedious but nobody knows your name if you do it.

Your talking about the attached check box right - see attached.

The point trying to get across to you is even if you rename the cert or config file so it doesn't have the user name on it - its still in the CERT file, while sure grandma can not read it.. But anyone else could with the simple url I posted..

So here is test cert I created.
-----BEGIN CERTIFICATE-----
MIIEfTCCA2WgAwIBAgIBDDANBgkqhkiG9w0BAQsFADByMQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCSUwxEzARBgNVBAcTClNjaGF1bWJ1cmcxDTALBgNVBAoTBEhvbWUx
IDAeBgkqhkiG9w0BCQEWEWpvaG5wb3pAZ21haWwuY29tMRAwDgYDVQQDEwdvcGVu
dnBuMB4XDTE3MDMyODE5Mjc1MFoXDTI3MDMyNjE5Mjc1MFowbDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAklMMRMwEQYDVQQHEwpTY2hhdW1idXJnMQ0wCwYDVQQKEwRI
b21lMRwwGgYJKoZIhvcNAQkBFg1CaWxseUBib2IuY29tMQ4wDAYDVQQDEwViaWxs
eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPIcgUzTlfDQSh9mPo5h
JtLT1p6GGteyhmFB5BuOxZst5455TVvLXYtAN9Vv5mgHaU/CNETT9IesNotD3X+6
v0nYedWBfF5/qrie8YEx3AWaKkmjytNnEMC9WizhPsBOz5BKX2RjYV2gWIB0lrMn
aivnSOk2y4Cgj+uplB40zutThVeXbF6/4YdfLIIB/sFgTD0x31praFeMdI9sfLhL
JhvIdN7sNP1A4Kh06CQDfWonPXjY1AcxF03U7qUh1Y5KEcsoxq9wyiE/wPfI/K7U
shXDIM0jCn4TD3nKU0GY1UzKxX05mf2v1y4jo2RfASX2gLXgjdHv9oBod+Rulkae
MfkCAwEAAaOCASIwggEeMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMDEGCWCGSAGG
+EIBDQQkFiJPcGVuU1NMIEdlbmVyYXRlZCBVc2VyIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBTwSRxt0Aa8iQbQEl67QIqsiqsVsjCBnAYDVR0jBIGUMIGRgBTp/c2QgDww
c2urH9gAH3FdxRH3wqF2pHQwcjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAklMMRMw
EQYDVQQHEwpTY2hhdW1idXJnMQ0wCwYDVQQKEwRIb21lMSAwHgYJKoZIhvcNAQkB
FhFqb2hucG96QGdtYWlsLmNvbTEQMA4GA1UEAxMHb3BlbnZwboIBADATBgNVHSUE
DDAKBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAQEAUFMFWbpZgDfeYM5yX/tE
Gv0tShiSfwvgxyFzyM2QgwbqAsRQgsEs6buCa9TzOs3DICALaVCa9WjB5XrnN7+E
yokE0QM2UvOdPUYPR3I6sum/8Jog2kNzKMfme6nIIMJASUPWRBPnlgXV3bUXrso1
pSjU3OfTM8CO+I6rsLsv03c2ViOltdC1XPXEeEXgk5vxNxHkCB7HgztRSV/8RA2J
JpHPz3kZEo28gqlO+Pi6XFyaAe+UJBhwBoJ92X8L2B+xD0BH4EHSsIXB/HEZg0RQ
48QtBpqxQWtZtJwxr/RnSBKFPIOAj2NZHxPce7vJS/zGOQVAVCyPQD7/ht8v5Fry
og==
-----END CERTIFICATE-----
I can call/rename this cert anything I want.. So sure pfsense calls it say

pfsense-TCP-443-billy.p12

that p12 has the cert in it, can be de-encoded and show you the CN or username that has to match. Your just causing yourself extra work if you think this is adding security from anyone other than say your grandma.

Not sure where you think there is hostility.. I am just trying to explain that encoding is not encrypted.. And your not actually hiding that CN from anyone by renaming the cert or config file or whatever it is your taking the time to rename so it doesn't match the CN.. Since the CN is there for anyone to view that has access to the file.. Be it they ETs skill or not.. If they know anything about how openvpn works….

So if your going to do a check that the username has to match the CN then not having the CN/Username pop up in the openvpn gui makes no difference. What making sure the the username matches CN for is that Billy doesn't access the vpn with Susan's username and password.. If they have billy's cert then they have to know billys password along with having the cert.

The 2FA comes from having to have the cert and knowing the password. Knowing the username does not remove the 2nd Factor.. There is still something you have and something you know.

Oddly enough, a surprising number of people other than grandma wouldn't know this. 30 seconds of work adds an extra layer of security. Then come the password(s).

johnpoz

"30 seconds of work adds an extra layer of security. "

Sorry it doesn't - that is not how security works in IT..

Let me guess you also hide your SSID or don't broadcast it and use mac address filtering.. Since they are added layers of security? ;) Do you also turn off your dhcp server as another layer?

But yeah those keep grandma from hacking your wifi ;)

coffeecup25

@johnpoz:

"30 seconds of work adds an extra layer of security. "

Sorry it doesn't - that is not how security works in IT..

Let me guess you also hide your SSID or don't broadcast it and use mac address filtering.. Since they are added layers of security? ;) Do you also turn off your dhcp server as another layer?

But yeah those keep grandma from hacking your wifi ;)

No, I stand by my answer. The snark is irrelevant. Making something a little more difficult is good planning. The real security is not impaired if some nuisance security is tossed into the mix. It just makes brittle snobs all huffy.