On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden <rcritten@redhat.com> wrote:

Thomas Letherby wrote:
> Well, after poking around with the dates and a few restarts of services,
> IPA now starts seemingly cleanly at the current date, although the
> clients still don't seem to want to trust the CA, and I'm still seeing
> the old cert crop up.
>
> If I look at the cert that wasn't updating before, it now seems to
> contain three certs, the expired one and two new with much longer expiry
> dates.
>
> [root@xipa1 conf.d]# certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L -n
> "I.DOMAIN.NET <http://I.DOMAIN.NET> IPA CA" | grep Not
> Not Before: Sun Jun 17 09:06:38 2018
> Not After : Thu Jun 17 09:06:38 2038
> Not Before: Sun Jun 17 07:24:26 2018
> Not After : Thu Jun 17 07:24:26 2038
> Not Before: Thu Jun 08 06:51:04 2017
> Not After : Mon Jun 18 06:51:04 2018
>
> Is this correct, or has it not updated the certificate correctly, if so,
> how do I clean it up?

This is rather confusing output. I think we need to see the full
certutil -L -d output to know what is going on. Did you run
ipa-cacert-manage renew at some point?

rob

>
> Thanks,
>
> Thomas
>
>
> On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS
> <christophe.trefois@uni.lu <mailto:christophe.trefois@uni.lu>> wrote:
>
> From that I know you could trigger a refresh by restarting certmonger.
>
>> On 9 Jul 2018, at 07:38, Thomas Letherby via FreeIPA-users
>> <freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>> wrote:
>>
>> Hello Fraser,
>>
>> As I've been playing around with this before I dig in further I
>> pulled the expiry for the certificates across all the places I
>> know to look, if I have a cert listed, it's expired:
>>
>> certutil -d /etc/pki/pki-tomcat/alias -L Up to date
>>
>> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L
>> I.DOMAIN.NET <http://i.domain.net/> IPA CA
>>
>> certutil -d /etc/httpd/alias -L
>> Signing-Cert
>> I.DOMAIN.NET <http://i.domain.net/> IPA CA
>>
>> getcert-list all up to date.
>>
>> ipa-getcert list all up to date
>>
>> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b "cn=I.DOMAIN.NET
>> <http://i.domain.net/> IPA
>> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net"
>> Expired
>>
>> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
>> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate
>> 1 - Expired
>> 2 - Expired
>> 3 - In date
>>
>> I've managed to narrow down the expiries to a crossover of one
>> day, and setting the date to that day allows Tomcat-PKI to start,
>> but the above results show that the certs haven't updated yet, but
>> they may do in the next few hours?
>>
>> Thomas
>>
>>
>>
>> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale
>> <ftweedal@redhat.com <mailto:ftweedal@redhat.com>> wrote:
>>
>> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas Letherby wrote:
>> > Hello Fraser,
>> >
>> > The serial numbers appear to match, but if I run
>> ipa-certupdate I get the
>> > following:
>> >
>> > ipa-certupdate
>> > trying https://server1.i.domain.net/ipa/json
>> > Connection to https://server1.i.domain.net/ipa/json failed
>> with [SSL:
>> > CERTIFICATE_VERIFY_FAILED] certificate verify failed
>> (_ssl.c:579)
>> >
>> > Tomcat is the only service that appears to be failing with
>> the following
>> > error:
>> >
>> > Internal Database Error encountered: Could not connect to
>> LDAP server host
>> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636
>> Error netscape.ldap.LDAPException: Unable to
>> > create socket: org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake
>> failed: (-8181)
>> > Peer's Certificate has expired. (-1)
>> >
>> > But it should now be valid as I set the date back. If I set
>> the date to
>> > today I get this error:
>> >
>> > Internal Database Error encountered: Could not connect to
>> LDAP server host
>> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net/> port 636
>> Error netscape.ldap.LDAPException: Unable to
>> > create socket: org.mozilla.jss.ssl.SSLSocketException:
>> > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake
>> failed: (-12195)
>> > Peer does not recognize and trust the CA that issued your
>> certificate. (-1)
>> >
>> > Looks like it can't load because the certificate it uses
>> isn't valid, if I
>> > roll the clock back so the CA cert is, the certificate
>> Tomcat is using
>> > isn't valid and if I roll forward the CA cert isn't.
>> >
>> > How can I break this catch 22?
>> >
>> Which is the not-yet-valid certificate at the time to which you
>> rolled back? The subsystemCert or the 389DS server certificate?
>>
>> In either case, you can look in the Dogtag certificate repository
>> (ou=certificateRepository,ou=ca,o=ipaca) for a version of the
>> certificate that is valid at the relevant time. Copy the cert
>> data
>> (you can base64-decode the value to get the binary DER certificate
>> data). Then you can delete the not-yet-valid-at-that-time
>> certificate from the NSSDB and add the appropriate certificate
>> using
>>
>>    certutil -d <nssdb-path> -A -i <cert-path>
>>
>> If the certificate in question is the Dogtag subsystemCert,
>> you will
>> furthermore need to fix up the data in the uid=pkidbuser entry to
>> match the "current" certificate.
>>
>> HTH,
>> Fraser
>>
>>
>> > Thanks,
>> >
>> > Thomas
>> >
>> >
>> >
>> >
>> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale
>> <ftweedal@redhat.com <mailto:ftweedal@redhat.com>>
>> > wrote:
>> >
>> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas Letherby
>> wrote:
>> > > > Hello all,
>> > > >
>> > > > Here's the info:
>> > > >
>> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L
>> > > >
>> > > > Certificate Nickname
>>    Trust
>> > > > Attributes
>> > > >
>> > > > SSL,S/MIME,JAR/XPI
>> > > >
>> > > > Server-Cert
>>    u,u,u
>> > > > O=domain,ST=Arizona,C=US
>>    CT,C,C
>> > > > I.domain.NET <http://i.domain.net/> IPA CA
>>    CT,C,C
>> > > >
>> > > > I.domain.NET <http://i.domain.net/> IPA CA is out of
>> date for those.
>> > > >
>> > > Try running ipa-certupdate. It will update the IPA CA
>> certificate
>> > > in the various trust stores including the DS NSSDB.
>> > >
>> > > It reads the certificates from
>> > >
>> > > cn=YOUR.DOMAIN IPA CA,cn=certificates,cn=ipa,cn=etc,{basedn}
>> > >
>> > > so you should probably check that the certificate in that
>> entry is
>> > > up to date also.
>> > >
>> > > Cheers,
>> > > Fraser
>> > >
>> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n
>> 'subsystemCert cert-pki-ca'
>> > > -a
>> > > > Not After : Fri Jun 05 01:32:01 2020
>> > > > Matches
>> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b
>> > > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)"
>> usercertificate
>> > > >
>> > > > Thomas
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden
>> <rcritten@redhat.com <mailto:rcritten@redhat.com>>
>> > > wrote:
>> > > >
>> > > > > Thomas Letherby via FreeIPA-users wrote:
>> > > > > > Hello Florence,
>> > > > > >
>> > > > > > It was the Signing-Cert and the I.domain.NET
>> <http://i.domain.net/> <http://I.domain.NET
>> <http://i.domain.net/>>
>> > > IPA
>> > > > > > CA cert. By setting the clock back I managed to get
>> those to renew,
>> > > now
>> > > > > > it seems I just need to get tomcat-pki to start.
>> > > > > >
>> > > > > > The error is:
>> > > > > >
>> > > > > > Internal Database Error encountered: Could not
>> connect to LDAP server
>> > > > > > host xipa1.i.xrs444.net
>> <http://xipa1.i.xrs444.net/> <http://xipa1.i.xrs444.net
>> <http://xipa1.i.xrs444.net/>> port 636 Error
>> > > > > > netscape.ldap.LDAPException: Unable to create socket:
>> > > > > > org.mozilla.jss.ssl.SSLSocketException:
>> > > > > > org.mozilla.jss.ssl.SSLSocketException:
>> SSL_ForceHandshake failed:
>> > > > > > (-12195) Peer does not recognize and trust the CA
>> that issued your
>> > > > > > certificate. (-1)
>> > > > > >
>> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L
>> > > > > >
>> > > > > > Certificate Nickname
>>    Trust
>> > > > > > Attributes
>> > > > > >
>> > > > > > SSL,S/MIME,JAR/XPI
>> > > > > >
>> > > > > > Server-Cert cert-pki-ca
>>    u,u,u
>> > > > > > ocspSigningCert cert-pki-ca
>>    u,u,u
>> > > > > > O=domain,ST=Arizona,C=US
>>    CT,C,C
>> > > > > > auditSigningCert cert-pki-ca
>>    u,u,Pu
>> > > > > > subsystemCert cert-pki-ca
>>    u,u,u
>> > > > > > caSigningCert cert-pki-ca
>> > > CTu,Cu,Cu
>> > > > > >
>> > > > > > These are all set to expire in 2020 or beyond.
>> > > > > >
>> > > > > > certutil -d /etc/httpd/alias -L Server-Cert
>> > > > > >
>> > > > > > Certificate Nickname
>>    Trust
>> > > > > > Attributes
>> > > > > >
>> > > > > > SSL,S/MIME,JAR/XPI
>> > > > > >
>> > > > > > Signing-Cert
>>    u,u,u
>> > > > > > O=xrs444,ST=Arizona,C=US
>>    CT,C,C
>> > > > > > I.XRS444.NET
>> <http://i.xrs444.net/> <http://I.XRS444.NET
>> <http://i.xrs444.net/>> IPA CA
>> > > > > > CT,C,C
>> > > > > > Server-Cert
>>    u,u,u
>> > > > > >
>> > > > > > I.XRS444.NET
>> <http://i.xrs444.net/> <http://I.XRS444.NET
>> <http://i.xrs444.net/>> IPA CA and Signing-Cert are the
>> > > > > > expired certs here.
>> > > > >
>> > > > > Don't worry about Signing-Cert. It is the cert used to
>> sign the jar
>> > > file
>> > > > > used to autoconfigure Firefox. You should never need
>> to re-sign one
>> > > > > again (and this method isn't allowed in modern Firefox
>> anyway).
>> > > > >
>> > > > > rob
>> > > > >
>> > > > > >
>> > > > > > Thomas
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence Blanc-Renaud <
>> > > flo@redhat.com <mailto:flo@redhat.com>
>> > > > > > <mailto:flo@redhat.com <mailto:flo@redhat.com>>> wrote:
>> > > > > >
>> > > > > > On 06/27/2018 07:02 AM, Thomas Letherby via
>> FreeIPA-users wrote:
>> > > > > > > After some fiddling with dates some more I
>> seem to have the
>> > > HTTPD
>> > > > > > cert
>> > > > > > > in sync, however it appears the cert signing
>> cert is expired.
>> > > > > > >
>> > > > > > > named also says it's starting, but doesn't
>> seem to want to
>> > > respond.
>> > > > > > >
>> > > > > > > I don't have time to dig into it more tonight,
>> but let me know
>> > > what
>> > > > > > > other information or tests I can run and I'll
>> get them posted
>> > > > > > tomorrow.
>> > > > > > >
>> > > > > > > Thanks all.
>> > > > > > >
>> > > > > > > Thomas
>> > > > > > >
>> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM Thomas Letherby <
>> > > xrs444@xrs444.net <mailto:xrs444@xrs444.net>
>> > > > > > <mailto:xrs444@xrs444.net
>> <mailto:xrs444@xrs444.net>>
>> > > > > > > <mailto:xrs444@xrs444.net
>> <mailto:xrs444@xrs444.net> <mailto:xrs444@xrs444.net
>> <mailto:xrs444@xrs444.net>>>> wrote:
>> > > > > > >
>> > > > > > > Hello,
>> > > > > > >
>> > > > > > > I think this is everything (domain name
>> changed to protect
>> > > the
>> > > > > > > guilty!):
>> > > > > > >
>> > > > > > > https://pastebin.com/bF1KR7VJ
>> > > > > > >
>> > > > > > Hi Thomas,
>> > > > > >
>> > > > > > in the provided pastebin, the error 'certutil:
>> function failed:
>> > > > > > SEC_ERROR_LEGACY_DATABASE: The certificate/key
>> database is in an
>> > > old,
>> > > > > > unsupported format' can be easily explained:
>> there is a typo in
>> > > the
>> > > > > > directory path.
>> > > > > > You can try with certutil -d
>> /etc/pki/pki-tomcat/alias -L -n
>> > > > > <nickname>
>> > > > > > (note the pki-tomcat instead of pki-tomcat*d*).
>> > > > > >
>> > > > > > You mention that the cert signing cert is
>> expired, can you
>> > > clarify
>> > > > > > which
>> > > > > > certificate this is? Please provide the subject
>> name, certificate
>> > > > > > nickname and location.
>> > > > > >
>> > > > > > Flo
>> > > > > > > I pulled the same on the replica, which
>> appears to be
>> > > playing
>> > > > > > up too
>> > > > > > > in a similar fashion.
>> > > > > > >
>> > > > > > > I did just notice the date on the replica
>> is out, I never
>> > > set
>> > > > > it
>> > > > > > > back when I was trying to get the cert to
>> renew.
>> > > > > > >
>> > > > > > > Let me know if you need anything else.
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Thomas
>> > > > > > >
>> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM Fraser
>> Tweedale
>> > > > > > <ftweedal@redhat.com
>> <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>> <mailto:ftweedal@redhat.com>>
>> > > > > > > <mailto:ftweedal@redhat.com
>> <mailto:ftweedal@redhat.com> <mailto:ftweedal@redhat.com
>> <mailto:ftweedal@redhat.com>>>>
>> > > > > wrote:
>> > > > > > >
>> > > > > > > On Fri, Jun 22, 2018 at 11:16:21PM
>> -0700, Thomas
>> > > Letherby
>> > > > > via
>> > > > > > > FreeIPA-users wrote:
>> > > > > > > > Hello all,
>> > > > > > > > I had an issue a short while ago
>> with a replica
>> > > which
>> > > > > > turned
>> > > > > > > out to be an
>> > > > > > > > expired certificate which I renewed
>> and all seemed
>> > > good.
>> > > > > > > >
>> > > > > > > > Seemed...
>> > > > > > > >
>> > > > > > > > It now appears that although the
>> certificate
>> > > renewed as
>> > > > > > seen
>> > > > > > > by getcert
>> > > > > > > > -list, it didn't update
>> /etc/httpd/alias and so the
>> > > > > > httpd and
>> > > > > > > tomcat-pki
>> > > > > > > > services won't start unless I set
>> the date to
>> > > before the
>> > > > > > > certificate
>> > > > > > > > expired, and even then sometimes
>> the httpd error_log
>> > > > > shows:
>> > > > > > > > Unable to verify certificate
>> 'Server-Cert'. Add
>> > > > > > > "NSSEnforceValidCerts off"
>> > > > > > > > to nss.conf so the server can start
>> until the
>> > > problem
>> > > > > > can be
>> > > > > > > resolved.
>> > > > > > > > and the service fails to start.
>> > > > > > > >
>> > > > > > > Hi Thomas,
>> > > > > > >
>> > > > > > > Can you please show `getcert list`
>> output on the
>> > > server in
>> > > > > > question,
>> > > > > > > as well as the output of
>> > > > > > >
>> > > > > > > certutil -d /etc/httpd/alias -L
>> Server-Cert
>> > > > > > >
>> > > > > > > and
>> > > > > > >
>> > > > > > > certutil -d
>> /etc/pki/pki-tomcatd/alias -L
>> > > <nickname>
>> > > > > > >
>> > > > > > > for each nickname in the
>> /etc/pki/pki-tomcatd/alias
>> > > NSSDB.
>> > > > > > >
>> > > > > > > And Certmonger journal output. And
>> pki debug log
>> > > > > > > /var/log/pki/pki-tomcat/ca/debug.
>> > > > > > >
>> > > > > > > It is strange that `getcert list'
>> shows an up to date
>> > > > > > certificate
>> > > > > > > while the actual certificate that is
>> being tracked is
>> > > > > > expired...
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > > Fraser
>> > > > > > >
>> > > > > > > > I've tried resubmitting the
>> certificate, and it
>> > > doesn't
>> > > > > > seem
>> > > > > > > to throw an
>> > > > > > > > error, but it doesn't update /alias
>> either.
>> > > > > > > > Trying to access the server via the
>> web page shows
>> > > the
>> > > > > old
>> > > > > > > certificate
>> > > > > > > > still in use.
>> > > > > > > > I see the same certificate error
>> with the replica
>> > > > > server,
>> > > > > > > which was freshly
>> > > > > > > > rebuilt and added last week.
>> > > > > > > > I've doubtless dug further into the
>> hole trying to
>> > > > > > > troubleshoot this, so I
>> > > > > > > > probably need to start from the
>> beginning again,
>> > > and a
>> > > > > > > pointer in the right
>> > > > > > > > direction would be a great help!
>> > > > > > > >
>> > > > > > > > A getcert list shows all the
>> certificates expiry
>> > > dates
>> > > > > well
>> > > > > > > into the future.
>> > > > > > > >
>> > > > > > > > How can I get the certs back in
>> sync? I've found a
>> > > few
>> > > > > > guides
>> > > > > > > and most seem
>> > > > > > > > to be for earlier versions, and I'm
>> not sure if
>> > > they're
>> > > > > > still
>> > > > > > > current.
>> > > > > > > >
>> > > > > > > > I can post whatever logs you think
>> will help, I'm
>> > > > > > afraid I'm
>> > > > > > > not familiar
>> > > > > > > > enough with them all to tell which
>> are the most
>> > > > > > relevant. Is
>> > > > > > > there a guide
>> > > > > > > > for the logs?
>> > > > > > > >
>> > > > > > > > Thanks for any help you can give,
>> > > > > > > >
>> > > > > > > > Thomas
>> > > > > > >
>> > > > > > > >
>> _______________________________________________
>> > > > > > > > FreeIPA-users mailing list --
>> > > > > > > freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> > > > > > <mailto:freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>>
>> > > > > > >
>>   <mailto:freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> > > > > > <mailto:freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>>>
>> > > > > > > > To unsubscribe send an email to
>> > > > > > >
>>   freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > > > > >
>>   <mailto:freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>>
>> > > > > > >
>>   <mailto:freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > > > > >
>>   <mailto:freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>>>
>> > > > > > > > Fedora Code of Conduct:
>> > > > > > > https://getfedora.org/code-of-conduct.html
>> > > > > > > > List Guidelines:
>> > > > > > >
>>   https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > > List Archives:
>> > > > > > >
>> > > > > >
>> > > > >
>> >
>> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > _______________________________________________
>> > > > > > > FreeIPA-users mailing list --
>> > > freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> > > > > > <mailto:freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>>
>> > > > > > > To unsubscribe send an email to
>> > > > > > freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > > > > >
>>   <mailto:freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>>
>> > > > > > > Fedora Code of Conduct:
>> > > https://getfedora.org/code-of-conduct.html
>> > > > > > > List Guidelines:
>> > > > > >
>>   https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > > List Archives:
>> > > > > >
>> > > > >
>> >
>> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/RAEH5S7INPORXEK7ZKGQTLXEHH3CH4S4/
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > _______________________________________________
>> > > > > > FreeIPA-users mailing list
>> -- freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> > > > > > To unsubscribe send an email to
>> > > > > freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > > > > > Fedora Code of
>> Conduct: https://getfedora.org/code-of-conduct.html
>> > > > > > List Guidelines:
>> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > > > > > List Archives:
>> > > > >
>> >
>> > https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/GTA5E2BV7VO24KL25TST5DTDXRAYOKDG/
>> > > > > >
>> > > > >
>> > > > >
>> > >
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> <mailto:freeipa-users@lists.fedorahosted.org>
>> To unsubscribe send an email to
>> freeipa-users-leave@lists.fedorahosted.org
>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines:
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List
>> Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/Z2CWAOM4HBHXWBCQRFJXFCHMOEBRFPPO/
>