1、首先打开I电脑桌面，单击此电脑右键选择属性按钮。
2、进入系统属性设置界面，选择远程按钮。
3、然后需要单击选择用户选项。
4、然后需要选择添加选项按钮。
5、单击高级选项，选择立即查找选项。
6、找到你授权远程的用户。
7、选择你需要的用户单击确定即可。
电子印章管理子系统分为七大功能模块：电子印章申请、电子印章制作、印章印模管理、电子印章管理、系统日志审计（统计报表）、系统设置管理、软件自动升级管理。 主要是完成系统基础数据的设置，包括组织机构设置、系统用户管理、系统角色管理、系统权限管理等功能。
a) 组织机构设置：设置电子印章制作系统中涉及的组织机构，本系统支持多级组织机构，支持树型组织机构的管理，进而使得电子印章制作系统支持集众部署，分级管理的应用模式。
b) 系统用户管理：输入电子印章用户的基本信息，并且给特定用户分配一定的角色，便于为特定用户群分配系统权限。
c) 系统角色管理：设置系统角色，通过角色，把相同性质的用户组织在一起，便于系统权限的分配。
d) 系统权限管理：为特定角色的用户分配系统权限，支持分级授权制章和分级审计管理。 在 电子签章系统中，我们建议设置以下几个角色，即平台管理员、系统管理员、印章管理员、印章使用人四种角色。
a) 平台管理员：是最高级管理员，主要具备以下功能：
n 系统设置管理（全部功能）
n USBKEY管理（全部功能）
平台管理员的角色是由系统（开发人员）设定的，不可以随便更改。
b) 系统管理员：
n USBKEY管理（全部功能）。
n 系统设置管理：可以添加组织机构、用户、分配角色，调整组织机构，但是不可以进行权限分配、角色增加等，角色增减和权限管理都由平台管理员完成，但是可以给一个用户分配角色。
n 印章印模管理（全部功能）。
n 电子印章制作（全部功能）。
n 电子印章管理：挂失印章、销毁印章、授权。
n 信息查询管理：查询相关信息。
系统管理员应该具备哪些权限，由平台管理员设定。
c) 印章管理员：具备除了系统设置管理、USBKEY管理之外的所有功能权限。市公安局、各区、县公安局、二级局、交管支队都具有印章管理员。也可以根据需要设置部门印章管理员的角色，但是一般情况下不需要。
d) 印章使用人：作为最终的签章用户，可以通过用户登录进入电子签章平台系统，并且可以进行以下 *** 作：
n 变更印章授权：就是改变印章管理人员，相当于目前的“重新授权”。这个时候，可以直接在授权选择框中输入新的管理人员，而不必从组织机构中选择，因为新人可能在系统中找不到。
n 查看系统日志：查看与登录用的USBKEY对应的所有电子印章的用章日志、系统 *** 作日志等全部日志信息。可以设定条件。
n 软件升级管理：执行该功能，可以主动实现客户端签章软件的升级。不过，一般情况下，登录系统时，会执行一次升级 *** 作。
电子印章管理系统界面
认证系统
电子签名认证系统包括了电子印章认证模块、网页签章服务器端组件、信息加密解密组件，构成一个集成的电子认证服务器系统。由于各个认证模块采用相同的软件结构和开发语言，因此可以视为一个综合认证服务器软件。
签名认证失败可能会导致应用程序无法正常启动，或者在使用时出现错误。这种情况下，您可以尝试重新安装应用程序，或检查是否需要更新应用程序版本。如果问题仍然存在，您可能需要联系应用程序开发商或设备厂商以获取更多帮助。
另外，确保您的设备时间和日期设置正确，因为这也可以影响数字签名的验证
在电子签章系统中涉及很多认证和控制流程，这里主要对印章申请、印章制作、签章认证、文档验证等流程。这些流程在遵循公安部的基本要求的前提之下，在安全性和严密性方面得到了加强，在此描述如下。 印章申请是指使用单位通过电子印章制作系统的用户界面填写电子印章使用申请，申请经过审核后才可以进入印章制作环节，审批未被批注，则退回申请。印章申请流程如下图所示。
印章申请流程 印章申请在经过审批之后，即自动进入制作流程：
a) 制章时，首先验证是否连接上制章授权卡，制章授权卡是由本 统一管理和发放的，制章时必须持有制章授权卡USBkey。如果验证通过，即检测到合法的制章授权卡，则进入下一步；
b) 否则终止制章，提示“未插制章授权卡，制章失败”，并且写入制章失败原因。通过制章授权卡验证之后，进行数字证书的验证，我们规定，在制作电子印章之前，USBkey中必须拥有合法的数字证书。如果数字证书验证通过，则说明该USBkey中拥有合法的数字证书，进入
c) 如果验证失败或者USBkey中没有任何数字证书，则终止制章流程，提示“数字证书不合法或无数字证书，制章失败”，并且写入制章失败原因到日志当中。
印章制作流程
d) USBkey中的数字证书验证通过之后，还要检测该USBkey是否已经制成了电子印章在使用中，如果在作为电子印章使用，则退出制章流程，提示“USBkey正在被某个电子印章使用”，写入制章失败原因到日志数据库；如果没有被使用，则进入下一步。
e) 执行制章命令，把对应的印模加密存储于USBkey或者以加密数据格式存储于数据库中。如果制章成功，返回“制章成功”，如果制章失败，就提示“制章失败”，并将对应信息写入制章日志中。 进行电子签章时需要联机验证电子印章卡，验证通过，则执行电子签章；验证未通过则提示电子签名认证子系统返回的验证失败原因。无论签章成功与失败，都自动写入签章日志。电子印章卡的验证流程如下图五所示。电子印章卡验证首先要检测是否可以连接到认证服务器，如果不能够正确连接到认证服务器，则需要检查系统设置。
a) 如果成功连接到认证服务器，则首先检查该电子印章是否在该电子印章管理子系统中有注册，如果有注册，则说明该电子印章具备在该系统中使用的权限，如果没有，则即使该电子印章是合法有效的，也不可以在当前认证系统所连接的电子印章管理子系统中使用。
b) 检验印章卡是否连接上，如果没有来年接上，就退出签章流程，提示“请插入电子印章卡”；连接上则进入下一步。
c) 加盖样章、样章定位：加盖上样章，并利用鼠标拖动样章到指定位置，点击鼠标右键，选择“文档签章”命令，系统提示输入USBkey的保护密码，连续5次输入错误，将退出签章流程，提示“密码错误，签章失败”，并写入签章日志；密码输入正确则进入电子印章的联机验证流程。在 综合警务平台或OA系统中没有加盖样章和手动定位的步骤，而是通过接口实现自动定位，直接成正章。
d) 客户端程序从USBkey中读取需要认证的信息提交到服务器端交由电子签名认证系统进行认证，如果验证未通过，则直接写日志到数据库中，认证通过则返回有关参数到客户端程序，有客户端程序执行电子签章运算，如果成功完成，则会提示“签章成功”，如果失败，则会提示“签章失败”，一般来说，如果不是用户在进行电子签章过程中执行了其它 *** 作，电子签章的运算和电子印章的显示都可以顺利完成。
签章认证流程 a) 执行已签章文档验证功能，首先进行签章者身份认证，由于是签章后的验证，所以只需要验证签章者所用数字证书是否为合法机构颁发的即可。而不必去验证数字证书是否在有效性之内以及废止证书列表验证。验证数字证书时，首先连接电子签名认证服务器，如果连接成功则提交证书到认证服务器验证，如果无法连接认证服务器，则d出文件选择框，提示选择用于验证签名证书合法性的签发机构的根证书。如果签名证书验证合法，则进入b）；验证不合法则中断验证流程，直接写入验证失败的原因到日志文件中。
文档验证流程
b) 文档内容验证：证书验证合法后，则自动进行文档内容验证，以鉴别文档内容在传输过程中是否被篡改，无论验证是否通过，都将进入c)印章印模验证，只是如果文档内容验证失败，则向印章管理系统写日志，验证通过则不写日志。
c) 印章印模验证：文档内容验证后，则自动进行印章印模验证，以鉴别印章印模在传输过程中是否被篡改，如果验证失败，则向印章管理系统写日志，验证通过则不写日志。
在完成所有的验证之后，系统将在一个界面中显示各项验证项目的验证结果。
所有的概念都基于一个非常重要的基础：
rsa 非对称加密算法 ：
先感受下几个概念
PKI。
PKI是公钥基础设施（Public Key Infrastructure) 包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。
我们关注就俩东西： PKCS 证书机构CA 。前者是定义加密算法，签名，证书相关的各种事情采用的协议。后者可以为我们颁发权威的证书。
PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。RSA算法可以做加密、解密、签名、验证，还有RSA的密钥对存储。这些都需要标准来规范，如何输入，如何输出，如何存储等。
PKCS。全称是公钥密码学标准， 目前共发布过 15 个标准，这些标准都是协议。总结一下 就是对加密算法，签名，证书协议的描述。下面列举一些常用的协议，这些协议在本文都会对应上。
这些协议具体的实现就体现在openssl等工具中， 以及jdk工具keytool jdk java第三方库bouncycastle。
比如用openssl 如何生成公/私钥(PKCS#1)、签名(PKCS#1 )、签名请求文件（KCS#10）、 带口令的私钥（PKCS#8）。 含私钥的证书（PKCS#12）、证书库（PKCS#12）
其中涉及到算法的基础协议PKCS#1等，由于涉及到密码学原理所以我们并不需要深究它，只要知道怎么做就可以了。
现实中我们要解决这样一种情况:
客户端和服务器之间的数据要进行加密。需要两个达成同一个对称秘钥加密才行，那么这个秘钥如何生成，并在两边都能拿到，并保证传输过程中不被泄露。 这就用到非对称加密了。 后续的传输，就能用这个 对称秘钥来加密和解密了。
还有这样一个问题：
就是客户端如何判断服务端是否是合法的服务端。这就需要服务端有个id来证明它，而这个id 就是证书，而且必须是权威机构颁发的才能算是合法的。
因为客户端即浏览器，认定证书合法的规则必须通过第三方来确认 即ca颁发的证书。否则就我可能进了一个假网站。
而这两个问题 都是ssl协议要解决的内容。
所以ssl协议做了两件事情，一是验证身份，二是协商对称秘钥，并安全的传输。 而实现这个过程的关键数据模型就是证书， 通过证书中的ca对证书的签名，实现了身份验证，通过证书中的公钥，实现对对称秘钥加密，从而实现数据保密。 其实还顺手做了一件事情就是通过解密签名比对hash，保证了数据完整性。
明白ssl协议 首先明白几个重要的概念：
证书： 顾名思义就是提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份z，由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书， 就是可以认定是合法身份的。客户端不需要证书。 证书是用来验证服务端的。
一般的证书都是x509格式证书，这是一种标准的证书，可以和其他证书类型互相转换。完整来说证书包含，证书的内容，包括 版本号， 证书序列号， hash算法， 发行者名称，有效期， 公钥算法，公钥，签名（证书原文以及原文hash一起签名）而这个内容以及格式 都是标准化的，即x509格式 是一种标准的格式。
签名: 就用私钥对一段数据进行加密，得到的密文。 这一段数据在证书的应用上就是 对证书原文+原文hash进行签名。
谁签的名，就是用谁的私钥进行加密。就像身份z一样， 合法的身份z我们都依据是政府签的，才不是假证， 那就是浏览器会有政府的公钥，通过校验（解密）签名，如果能够解密，就可以确定这个就是政府的签名。就对了。
hash算法 ：对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。比如，MD5和SHA-1及其大量的变体。 hash算法具有不可逆性，无法从摘要中恢复出任何的原始消息。长度总是固定的。MD5算法摘要的消息有128个比特位，SHA-1算法摘要的消息最终有160比特位的输出。
ca机构： 权威证书颁发机构，浏览器存有ca的公钥，浏览器以此公钥来验证服务端证书的合法性。
证书的获取： 生成证书申请文件csr（涉及到PKCS#10定义的规范）后向ca机构申请。 或者自己直接通过生成私钥就可以一步到位生成自签名证书。 自签名证书就是用自己的私钥来签名证书。
那么为了体现到 证书身份认证、数据完整、保密性三大特性 ，证书的简化模型可以认为包含以下两个要素：服务器公钥，ca的签名（被ca私钥加密过的证书原文+原文hash），
身份认证：
浏览器存有ca公钥，用ca公钥解密网站发给你的证书中的签名。如果能解密，说明该证书由ca颁发，证书合法。 否则浏览器就会报警告，问你是否信任这个证书，也就是这个网站。这时候的证书可以是任何人签发的，可以自己签发的。 但是中间人攻击。 完全伪造新的证书， 这就没有办法了。 所以还是信任证书的时候要谨慎。
数据完整：
如果你信任该证书的话，这时候就会用证书中的公钥去解密签名，如果是ca签发的证书，那么之前就已经通过ca的公钥去解密签名了。 然后得到证书hash，然后在浏览器重新对证书做hash，两者比对一致的话，说明证书数据没有被篡改。
保密性：
使用证书的公钥对对称秘钥加密保证传输安全，对称秘钥生成后，后续的传输会通过对称秘钥来在服务端和客户端的加解密。
那么ssl协议的具体过程就是：
4网站接收浏览器发来的数据之后 使用自己的私钥校验签名，并对原文进行hash 与解密出的hash 做比对检查完整性。然后发送编码改变通知，服务器握手结束通知（所有内容做hash ）。 发送给客户端校验。
5 客户端校验，校验成功后，之后就用 对称秘钥进行通信了。
总共的过程是 c-s-c- s-c 四次握手。
四次握手简单来说分别是：
1请求获取证书
2服务端返回证书，客户端验证了证书的合法性和完整性，同时生成了对称秘钥。
3客户端把加密的 对称秘钥发给服务器。服务器检查真实性和完整性。
4服务端返回握手结束通知，客户端再检查一次真实性和完整性。
前两次握手是明文， 后两次握手是密文。 所以都要检查身份真实性和数据完整性。
ca的作用：
ca起到一个权威中间人的角色，如果脱离了ca， 那么证书还是证书，还能加密，保证数据完整性。 但是无法应用在客户端去认定服务器身份合法这个场景下。
下面就详细说下 脱离了ca签发的证书的应用：
自签名证书：
证书如果没有权威机构的签名，就是没有权威机构给你签发身份z。 那么这时候身份认证的场景变了。
这时候的认证场景就变成了，不再是某个官方权威说了算，而是假设第一次碰到这个证书，会认为，这个证书与之捆绑的实体之间是合法的并做记录。如果当这个实体下次捆绑了另一个证书，那么就是非法的。
这种情况常用于android中安装和校验app的时候，会先假设第一次安装的是合法的应用，认定这个app证书中的公钥是合法的公钥。然后通过自签名的证书，校验签名，就能实现后续安装是否合法以及完整性。
android中的如何对app进行身份认定和不被篡改：
android系统在安装app时候会进行校验applicationId，applicationId 不同会认定为不同应用。相同应用，第二次安装会校验证书是否和之前app的证书相同，如果相同则两个包很可能来自同一个身份。 如果证书不同，也就是该包被另一个身份用自己的私钥重新签名过，就会拒绝安装。 然后通过公钥来解密签名，如果能解密，说明身份是ok的。否则拒绝安装。比对解密签名后的hash 与apk包内的certsf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。
android在提交应用商店的问题：
应用商店也会校验 后续的上传和第一次上传时的证书，以及类似上述的后续的一系列校验。防止合法的开发者平台被盗后，上传非法应用。
android在接入第三方sdk的问题：
接入第三方sdk 会提交applicationId 和 sha1 值。 这个sha1值就是对 证书原文的签名后的sha1，也就是证书指纹。这个证书是证书库里最初的那个证书（x509格式），而不是对apk签名后生成的证书(PKCS#7)。一般的证书签名的主体是证书原文本身，而对apk签名还额外会对apk所有文件生成的hash值文件（certsf）进行一次签名。
第三方平台会记录 applicationId 与sha1 的对应关系。 当有假冒app试图接入时候，由于会对app内的PKCS#7证书转换为原始的x509格式证书，重新生成sha1值，与用户提交sha1 比对， 如果相同则说明证书很可能是ok的。 因为sha1就是证书的指纹。 之后就会通过证书中的公钥来校验签名，从而最终确认身份合法性以及信息完整性。
第三方平台之所以需要用户去提交证书指纹sha1值，多了这一步，就意味着你的证书是可以更换的，一旦更换了证书，就必须提交新的指纹给我，然后我来做匹配。而应用商店没有这个功能， 一旦你的证书的私钥丢了， 那就必须重新建一个新的app。
总结来看证书的身份认定机制：
在ssl协议下，这种场景是 浏览器用于认定合法的服务器身份。 在自签名证书下，需要用户选择是否信任该证书。
在android app采用自签名证书的场景下， 证书起到了 假设第一次的证书合法，公钥合法，后续如果证书不一致或不能够完成签名校验，就是非法。
证书库：
证书库应该满足PKCS#12协议。 但是jdk提供了制作证书的工具keytool 可以生成keystore类型的证书库，后缀为jks。 keystore pk12可以通过keytool命令互相转换。
证书库是个证书的容器， 可以用来创建数字证书。 在keystore证书库中，所有的数字证书是以一条一条(采用别名alias区别)的形式存入证书库的。证书库中的证书格式为pk12，即包含私钥。 如果导出证书的话， 可以导出为x509不包含私钥的格式 或者pk12包含私钥的证书。 也可以也可以用-import参数加一个证书或证书链到信任证书。
android中一般都采用读取证书库的方式，通过证书库来创建一个证书，通过alias来区分。 所以在签名的时候，一个alias是一个证书，不同的alias是不同的证书，不要搞错了。
几个关系：
证书和非对称加密算法的关系：
证书代表一个身份的主体，包含了非对称秘钥体系中的公钥，以及用私钥对证书签名。这种组织结构，把非对称加密算法从加密的功能，拓宽到了用于身份认证，信息完整性上。这体现在了证书的作用。 本质还是利用了非对称加密算法的特性。
ssl协议和证书的关系。
因为证书解决了客户端对服务器的身份认证（自签名证书除外），同时也解决了加密，和信息完整性，所以ssl协议基于证书来实现。
openssl genrsa -out rootkey 2048
也可以是pem文件，也可为了区分这是私钥而改用key后缀名，内容如下：
查看详细解析：包含两个大素数和两个指数和一个系数
openssl rsa -in rootkey -text
可通过命令提取公钥：
openssl rsa -pubout -in rootkey
openssl req -new -out root-reqcsr -key rootkey -keyform PEM
-keyform PEM：证书有pem和der格式之分，前者文本，多用于java和windows服务器，后者二进制
CSR是Certificate Signing Request的英文缩写，即证书请求文件
openssl x509 -req -in root-reqcsr -out root-certcer -signkey rootkey -CAcreateserial -days 365
-CAcreateserial ，创建证书序列号，使用此选项，当CA序列号文件不存在时将被创建：它将包含序列号“02”，正在签名的证书将具有1作为其序列号。通常如果指定了-CA选项并且序列号文件不存在，则会出现错误。
-days 据说3650天有时候会意外导致证书验证失败，没遇到过
此处可有pem、crt、cer多种输出格式，其实内容都一样，来试一下：
每次生成的证书都不一样，但是未发现不同后缀名下的证书格式不同。
我的理解：
pem是最基本的编码格式，der也相同。
CRT文件是由第三方证书颁发机构（例如VeriSign或DigiCert）提供和生成的安全文件，ASCII编码格式。
cer是crt的微软形式。
为了统一，全使用cer格式。
可选择将证书和私钥导入密钥库，通常用p12和jks（ Java Key Store）格式：
openssl pkcs12 -export -in root-certcer -inkey rootkey -out rootp12 -name "lab"
需要加密保护， -name 设置别名
然后可选择使用keytool将p12转为jks格式，此处就不做转换了。
步骤基本相同
步骤基本相同
openssl genrsa -out server-keykey 2048
openssl req -new -out server-reqcsr -key server-keykey -keyform PEM
openssl x509 -req -in server-reqcsr -out server-certcer -CA F:\CERT\mycert\ test\openssl\win\root\root-certcer -CAkey F:\CERT\mycert\test\openssl\win\root\rootkey -CAcreateserial -days 360
openssl pkcs12 -export -in server-certcer -inkey server-keykey -out server p12 -name "lab-server"
运行环境要包含完整证书链。需要将证书链放到系统可信目录下。
为证书绑定ip，只能通过config文件，
文件如下可将常用参数写入，生成请求文件时直接enter即可：
使用配置文件时在生成请求文件和签发证书时的参数不同：
生成请求文件：
openssl req -new -out server-req1csr -key server-keykey -keyform PEM -extensions v3_req -config openssl cnf
签发证书：
openssl x509 -req -in server-req1csr -out server-cert1cer -CA F:\CERT\mycert\test\openssl\win\root\root- certcer -CAkey F:\CERT\mycert\test\openssl\win\root\rootkey -CAcreateserial -days 360 -extensions v3_req -extfile opensslcnf
默认证书链长度为2，使用中间ca签发时，中间ca的生成需要在配置文件中加修改长度参数：
[ v3_ca ]
basicConstraints = CA:true,pathlen:3
Note：
参考：
OpenSSL主配置文件opensslcnf
利用OpenSSL创建证书链并应用于IIS7
openssl系列文章： >
电子签名平台挺多的，关键还是要看用在什么场景下，用户的群体是什么样的，以及对法律合规性的要求。现在国内规模最大的是e签宝，也是中国第一家互联网电子签名平台，2002年成立，提供了一套从电子签名到文档归档管理、从存证保全到司法出证等全流程服务，不仅是浙江省政府“最多跑一次”指定电子签供应商，合作伙伴还包括阿里巴巴、索尼、华夏银行、海康威视、吉利、百威、顶新集团等顶级企业。
e签宝产品不仅通过国家密码管理局商用密码产品品种和型号审批，还拥有ISO27001信息安全管理体系认证，ISO27018云端个人数据保护认证、可信云服务认证，计算机信息系统安全专用产品检测、等保三级认证等，其中等保三级认证得分为全行业最高，也是国家“安全可靠技术和产业联盟”成员，在技术安全和权威资质方面属业界领先。
您好，目前国内可信的平台有 法大大、上上签和e签宝和易企签。
其他平台可以根据他们的这个问题的回答来了解 ，我在这里主要说一下易企签。
壹：
易企签如何保障电子合同的安全性？
一、数据安全
1 三级等保机房
易企签三级等保机房，保证物理、结构、主机、应用、数据等各方面的安全。其中，对于数据安全，易企签能够检测系统管理数据、鉴别信息和重要业务数据在传输过程中的完整性，且能通过加密或其他有效措施对数据进行安全保护。
2 金融级别数据可靠性
易企签采用金融级别的安全存储环境，有效防止篡改，保证数据的完整、一致和准确。
3 数据异地备份
易企签提供完善的安全存储环境，除本地备份外，还可以异地备份，有效保证用户数据信息的安全性和完整性。
二、签署安全
1 公安部、工商总局联网实名认证
2 签署意愿认证
在使用易企签进行合约签署时，需要输入签署密码，认证签署人的签署意愿，保证了合同签署内容是由签署双方出于公平自愿原则签署。
3 高强度数字加密
用户使用易企签进行在线审批、合同签署、在线传输、在线存储等服务的过程中，实现全程数字加密，保护用户隐私安全，防泄露、防篡改，保证电子合同的机密性与安全性。
三、传输安全
1 全站>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）