Linux/Unix

Enable LDAPS in Active Directory with OpenSSL

Posted on by Andy

Step 1: Create a Certificate Authority (CA) with OpenSSL

Use the following commands to create a CA with a validity period of 10 years. The CA can be created on any machine using OpenSSL:

openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

Go ahead and enter the asked information, here are some sample lines:

Country Name (2 letter code) [AU]: US
State or Province Name (full name) [Some-State]: New York
Locality Name (eg, city) []: New York
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MyCompany
Organizational Unit Name (eg, section) []: IT
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Step 2: Install the Certificate Authority (CA)

  • Open MMC (Microsoft Management Console) by opening PowerShell and typing “mmc”
  • when opened go to “File -> Add/Remove Snap-in”
  • and add “Certificates” to the list.
  • Click on “Next” and select “Computer Account”, “Next”, “Local Computer”
  • then “Finish” and go to the MMC window.
  • Under “Trusted Root Certification Authorities”, right-click on the “Certificates” node, select “All Tasks -> Import…” and import the certificate created in step 1.

Step 3: Create a Certificate Signing Request (CSR)

Create a new file with .inf extension (e.g. request.inf)

;----------------- request.inf -----------------
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=ad1.server.com,OU=IT Department,DC=domain,DC=local,O=MyCompany,L=New York,S=New York,C=US";
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = False
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1; this is for Server Authentication

Go ahead and change the Subject line to your needs. You could also raise the key length to 4096 if you want to.

Now that you created the file, create the signing request with:

certreq -new request.inf MyDC.csr

Step 4: Sign and accept the Certificate

You should now transfer the CSR back to the machine where you installed OpenSSL and sign the request with your CA and get the corresponding CRT:

openssl x509 -req -days 3650 -in MyDC.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out MyDC.crt

Transfer the created CRT file onto the server and execute in the PowerShell:

certreq -accept MyDC.crt

Step 5: Install the Certificate

Assuming MMC (Certificates) is still open, expand the “Certificates” node under “Personal”, right-click on the “Certificates” node, select “All Tasks -> Import…” and import MyDC.crt

Step 7: Restart Active Directory

All that’s left is to reboot your AD server. Done.

Enable TLSv1 in Ubuntu 20.04

Posted on by Andy

By default, Ubuntu 20.04, or better the used OpenSSL version, disables all ciphers below TLSv1.2 and you need to re-enable it in order to use older ciphers. It is quite simple, add following text at the top of /etc/ssl/openssl.cnf:

openssl_conf = default_conf

[ default_conf ]

ssl_conf = ssl_sect

[ssl_sect]

system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT:@SECLEVEL=1

Now reboot the machine and you should be done.

Warning: this can harm your machine, not physically but mentally. make sure you know how to restore the openssl.cnf if you have to.

ufs_dirbad panic with mangled entries on FreeBSD

Posted on by Andy

FreeBSD UFS makes usually a very good job in staying sane and repairing itself. However, it can happen that UFS is not capable of repairing and some “mangled entries” appear which result in kernel panics. Unfortunatlely these are not repairable by fsck. How do they look like?

/: bad dir ino 32578 AT OFFSET 33812: MANGLED ENTRY
panic: ufs_dirbad: bad dir

So what should we do if i encounter one of these lookalike messages? Well…

Reboot your machiine in single user mode, usually option 2 in the boot menu. After bootup start a filesystem check with repairing:

$ fsck -y /
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
112346 files, 42158044 used, 59151489 free (9993 frags, 7392687 blocks, 0.0% fragmentation)

Even if no error was found and the disk was marked clean, there can be problems with some inodes/files. You may bring your system back up without any further work, however if it panics again with the same message (check out the inode number -> ino), you are likely to have unfixable corruption.

Now how can you fix it? Use the filesystem debugger fsdb. Please note that in our example the concerned inode is 32578 (ino 32578 in our error message), this is likely to change in your error.

$ fsdb /dev/da0p2
** /dev/da0p2
Editing file system '/dev/da0p2'
Last mounted on /
...
fsdb (inum: 2)>

Now go to the inode mentioned in the panic and delete it: WARNING: you will lose data when you clear the inode! Keep it in mind.

fsdb (inum: 2)> inode 32578
...
fsdb (inum: 32578)> clri 32578
fsdb (inum: 32578)> quit

**** FILE SYSTEM STILL DIRTY *****
*** FILE SYSTEM MARKED DIRTY
*** BE SURE TO RUN FSDK TO CLEAN UP ANY DAMAGE
*** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload

Now start fsck again like in the beginning of this article. Run it until no more errors are shown and it is MARKED AS CLEAN.

That’s it. Reboot normally and hope that not more inodes are faulty. If so, repeat this for every inode throwing the initial error/panic.