quarkusio/quarkus · critical · SecurityException

Failed to set private key file readable by owner only. This

Error message

Failed to set private key file readable by owner only. This is a critical security requirement to protect the private key.

What it means

adjustPermissions() hardens the private key file by removing execute for all and restricting read to the owner only via File.setReadable(true, true). If the OS refuses to apply owner-only read permission, a SecurityException is thrown because leaving the key world-readable is considered an unacceptable security risk. The method deliberately fails closed rather than continuing with loose permissions.

Source

Thrown at extensions/tls-registry/cli/src/main/java/io/quarkus/tls/cli/letsencrypt/LetsEncryptHelpers.java:325

        }
        if (!certFile.setWritable(true, true)) {
            LOGGER.error("Failed to set certificate file writable by owner only");
        }

        // Private key MUST be owner-only readable/writable (chmod 600)
        if (!keyFile.setReadable(false, false)) { // Remove group/world read
            LOGGER.warnf("Failed to set key file readable only by the owner: %s", keyFile.getAbsolutePath());
        }
        if (!keyFile.setWritable(false, false)) { // Remove group/world write
            LOGGER.warnf("Failed to set key file writable only by the owner : %s", keyFile.getAbsolutePath());
        }
        if (!keyFile.setExecutable(false, false)) { // Remove group/world execute
            LOGGER.warnf("Failed to set key file executable by owner only: %s", keyFile.getAbsolutePath());
        }

        // Then set owner-only permissions
        if (!keyFile.setReadable(true, true)) { // Owner-only read
            throw new SecurityException("Failed to set private key file readable by owner only. " +
                    "This is a critical security requirement to protect the private key.");
        }
        if (!keyFile.setWritable(true, true)) { // Owner-only write
            throw new SecurityException("Failed to set private key file writable by owner only. " +
                    "This is a critical security requirement to protect the private key.");
        }

        AUDIT.debug("Set secure permissions on private key file: " + keyFile.getAbsolutePath() + " (owner-only: rw-------)");
        LOGGER.debug("Set secure permissions on private key file (owner-only: rw-------)");
    }
}

View on GitHub (pinned to e1c734241f)

Solutions

  1. Run the command as the user who owns the key file (or chown the file to the current user)
  2. Move the letsencrypt directory to a local POSIX filesystem (e.g. ext4) instead of a network share or Windows volume
  3. Verify parent directory permissions allow modifying the file, then retry renewal
  4. If on a platform without POSIX perms, ensure the environment guarantees isolation (container with restricted volume) before accepting the limitation

Example fix

// before
File keyFile = new File("/mnt/nfs/letsencrypt/site.key"); // NFS mount, perms not enforceable
// after
File keyFile = new File("/var/lib/quarkus/letsencrypt/site.key"); // local POSIX fs
Defensive patterns

Strategy: validation

Validate before calling

static boolean canSecureKeyFile(File f) {
    try {
        return f.isFile() && f.canWrite()
            && Files.getFileAttributeView(f.toPath(), PosixFileAttributeView.class) != null
            && Files.getOwner(f.toPath()).getName().equals(System.getProperty("user.name"));
    } catch (IOException e) { return false; }
}

Type guard

if (!Files.getFileAttributeView(keyFile.toPath(), PosixFileAttributeView.class).readAttributes().permissions().contains(PosixFilePermission.OWNER_READ)) { relocateFilesystem(); }

Try / catch

try {
    LetsEncryptHelpers.adjustPermissions(keyFile);
} catch (SecurityException e) {
    LOGGER.error("Cannot enforce owner-only permissions on " + keyFile + "; move to a local POSIX filesystem", e);
    throw new IllegalStateException("Refusing to store private key without owner-only permissions", e);
}

Prevention

When it happens

Trigger: keyFile.setReadable(true, true) returns false — occurs when the file is on a filesystem that does not support POSIX permissions (Windows NTFS/FAT, some network mounts, container volumes), when the process user is not the file owner, or when setReadable threw/failed due to SecurityManager restrictions.

Common situations: Running the CLI on Windows where owner-only permissions cannot be expressed, working directory on a mounted share (SMB/NFS) with permission mapping issues, running as a different user than the one that created the key file, or a SecurityManager denying file attribute changes.

Related errors


AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/6c07ec4d05647299. Report an issue: GitHub.